[gentoo-dev] Stabilisation of the slotted-Lua ecosystem

2021-01-22 Thread Marek Szuba

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

2021-01-17 Thread Marek Szuba

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

2021-01-04 Thread Marek Szuba



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

2020-12-23 Thread Marek Szuba



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

2020-12-22 Thread Marek Szuba
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

2020-12-21 Thread Marek Szuba
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

2020-12-09 Thread Marek Szuba

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

2020-12-09 Thread Marek Szuba

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

2020-12-07 Thread Marek Szuba

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

2020-12-05 Thread Marek Szuba



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

2020-12-04 Thread Marek Szuba
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

2020-12-04 Thread Marek Szuba

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

2020-11-30 Thread Marek Szuba

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

2020-11-29 Thread Marek Szuba

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

2020-11-29 Thread Marek Szuba

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

2020-11-28 Thread Marek Szuba
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

2020-11-24 Thread Marek Szuba

# 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

2020-11-11 Thread Marek Szuba

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

2020-11-10 Thread Marek Szuba

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

2020-11-09 Thread Marek Szuba

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

2020-11-09 Thread Marek Szuba

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?

2020-11-09 Thread Marek Szuba

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!

2020-11-05 Thread Marek Szuba

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

2020-11-04 Thread Marek Szuba

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

2020-11-03 Thread Marek Szuba
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

2020-11-03 Thread Marek Szuba
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!

2020-11-03 Thread Marek Szuba

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

2020-11-03 Thread Marek Szuba
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

2020-10-15 Thread Marek Szuba
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

2020-10-15 Thread Marek Szuba
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

2020-10-15 Thread Marek Szuba
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

2020-10-15 Thread Marek Szuba
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

2020-10-15 Thread Marek Szuba

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!

2020-10-14 Thread Marek Szuba

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

2020-10-13 Thread Marek Szuba

# 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()

2020-10-12 Thread Marek Szuba

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()

2020-10-12 Thread Marek Szuba
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()

2020-10-12 Thread Marek Szuba
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()

2020-10-12 Thread Marek Szuba
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

2020-10-12 Thread Marek Szuba
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

2020-10-12 Thread Marek Szuba

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

2020-10-06 Thread Marek Szuba
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

2020-10-05 Thread Marek Szuba
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

2020-10-05 Thread Marek Szuba
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

2020-10-05 Thread Marek Szuba
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

2020-10-05 Thread Marek Szuba
I have decided to add support for dev-lang/lua:0 because having thought
quite a lot about the transition path from Lua ebuilds as they are to
the new eclasses, it seems to be the most sane approach. Still, I hope
this will not stay around for too long.

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

2020-10-01 Thread Marek Szuba
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

2020-09-30 Thread Marek Szuba
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

2020-09-30 Thread Marek Szuba
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

2020-09-30 Thread Marek Szuba
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

2020-09-30 Thread Marek Szuba
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

2020-09-30 Thread Marek Szuba
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

2020-09-24 Thread Marek Szuba
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

2020-09-24 Thread Marek Szuba
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

2020-09-15 Thread Marek Szuba
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

2020-09-13 Thread Marek Szuba
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

2020-09-08 Thread Marek Szuba
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

2020-09-07 Thread Marek Szuba
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

2020-09-04 Thread Marek Szuba
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

2020-09-03 Thread Marek Szuba
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

2020-09-03 Thread Marek Szuba
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

2020-09-03 Thread Marek Szuba
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

2020-09-01 Thread Marek Szuba
# 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

2020-08-31 Thread Marek Szuba
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

2020-08-27 Thread Marek Szuba
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

2020-08-27 Thread Marek Szuba
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

2020-08-27 Thread Marek Szuba
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

2020-08-26 Thread Marek Szuba
# 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

2020-07-29 Thread Marek Szuba
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

2020-07-29 Thread Marek Szuba
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}

2020-07-27 Thread Marek Szuba
# 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

2020-07-27 Thread Marek Szuba
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

2020-07-27 Thread Marek Szuba
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

2020-07-27 Thread Marek Szuba
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

2020-07-27 Thread Marek Szuba
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

2020-07-26 Thread Marek Szuba
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

2020-07-25 Thread Marek Szuba
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

2020-07-11 Thread Marek Szuba

# 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

2020-07-01 Thread Marek Szuba
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

2020-06-26 Thread Marek Szuba
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]

2020-06-17 Thread Marek Szuba
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

2020-04-20 Thread Marek Szuba
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

2020-04-19 Thread Marek Szuba
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

2020-04-19 Thread Marek Szuba
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

2020-04-13 Thread Marek Szuba
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

2020-04-12 Thread Marek Szuba
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

2020-04-11 Thread Marek Szuba
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

2020-04-11 Thread Marek Szuba
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

2020-04-11 Thread Marek Szuba
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

2020-04-11 Thread Marek Szuba
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

2020-04-08 Thread Marek Szuba
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

2020-04-08 Thread Marek Szuba
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

2020-04-08 Thread Marek Szuba
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

2020-04-08 Thread Marek Szuba
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

2020-04-08 Thread Marek Szuba
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

2020-04-06 Thread Marek Szuba
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

2020-04-06 Thread Marek Szuba
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

2020-04-06 Thread Marek Szuba
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

2020-04-05 Thread Marek Szuba
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

2020-04-05 Thread Marek Szuba
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


  1   2   >