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

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

[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

[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

[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,

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

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

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

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

[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

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.

[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

[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

[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

[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

[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

[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

[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

[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

[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 --

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

[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

[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

[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

[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

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

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

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

[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

[gentoo-dev] [PATCH 1/2] lua-utils.eclass: Support luajit

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

[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

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

[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

[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

[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

[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

[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

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

[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

[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.

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

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

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" T

[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

[gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass

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

[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

[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]}" \ > +

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

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

[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

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

[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

[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

[gentoo-dev] [PATCH] eclass/sword-module.eclass: update SRC_URI, expand a bit, clean up

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

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

Re: [gentoo-dev] [RFC] sword-module.eclass: update, extend, increment revision

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

[gentoo-dev] [RFC] sword-module.eclass: update, extend, increment revision

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

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.

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,

[gentoo-dev] [PATCH] x11-drivers/nvidia-drivers: migrate to >=virtual-opencl-3

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

[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

[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

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

[gentoo-dev] News item v2: potential file collisions during OpenCL upgrade

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

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

[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

[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

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 b

[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

[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

[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

[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

[gentoo-dev] [PATCH] virtual/opencl: new version

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

[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

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

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. >>

[gentoo-dev] [PATCH] Refactor virtual/opencl to provide the API, not an implementation

2020-04-04 Thread Marek Szuba
As proposed in my e-mail to the list from two days ago. Advantage: OpenCL-aware ebuilds will have something to compile and link against regardless of whether the runtime invoked by the ICD loader supports abi_x86_32 or not, or indeed even if there is no suitable runtime in the Gentoo tree.

[gentoo-dev] [PATCH] virtual/opencl: new version

2020-04-04 Thread Marek Szuba
a postinst message. Signed-off-by: Marek Szuba --- virtual/opencl/opencl-3.ebuild | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 virtual/opencl/opencl-3.ebuild diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild new file mode 100644

[gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl

2020-04-02 Thread Marek Szuba
(with many thanks to everyone who mulled on this problem in #gentoo-dev yesterday, mattst88 in particular) So, yesterday's attempt to begin phasing support for 32-bit OpenCL out of Gentoo (which, to remind everyone who may not have followed the earlier discussion, would essentially acknowledge

Re: [gentoo-dev] Packages up for grabs: app-office/magicpoint, sys-apps/flashrom

2020-03-26 Thread Marek Szuba
On 2020-03-23 20:33, Jonas Stein wrote: > sys-apps/flashrom I'll take this one, I still use it from time to time. -- MS signature.asc Description: OpenPGP digital signature

[gentoo-dev] News item: Removing ABI_X86_32 support from virtual/opencl

2020-03-04 Thread Marek Szuba
from virtual/opencl Author: Marek Szuba Posted: 2020-03-09 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: virtual/opencl From April 2020 onwards virtual/opencl will no longer provide support for the 32-bit ABI on either multilib amd64 or native x86 systems. The reason for this is that most

[gentoo-dev] Last rites: dev-go/ed25519

2020-03-04 Thread Marek Szuba
Most of upstream code has got merged into x-crypto (dev-go/go-crypto), and since go-1.13 subsequently into the Go standard library. Original code is no longer maintained and contains known bugs. Removal in 30 days. Bug #711520. -- MS signature.asc Description: OpenPGP digital signature

[gentoo-dev] RFC: Removing ABI_X86_32 support from virtual/opencl

2020-02-28 Thread Marek Szuba
Hello, I think the time has come to follow the example of CUDA and stop supporting ABI_X86_32, both natively and in multilib configurations, in virtual/opencl. Let us have a quick look at OpenCL providers currently listed in virtual/opencl-2: 1. No 32-bit support: - dev-libs/intel-neo (Intel

[gentoo-dev] Last rites: dev-libs/beignet

2020-02-24 Thread Marek Szuba
Deprecated upstream in Q1'2018 in favour of dev-libs/intel-neo and while it officially remains the recommended solution for "legacy HW platforms" not supported by NEO (i.e. Sandy Bridge, Ivy Bridge and Haswell GPUs), there has been no repository activity since August 2018. Only really suitable

Re: [gentoo-dev] crypto@ packages up for grabs

2020-01-10 Thread Marek Szuba
On 2020-01-08 21:16, Mikle Kolyada wrote: > app-crypt/chntpw > app-crypt/rainbowcrack I'll take these two. -- MS signature.asc Description: OpenPGP digital signature

[gentoo-dev] [PATCH 2/2] acct-user/xrootd: new user for UID 469

2019-12-20 Thread Marek Szuba
man-2.3.16 Signed-off-by: Marek Szuba --- acct-user/xrootd/metadata.xml| 8 acct-user/xrootd/xrootd-0.ebuild | 12 2 files changed, 20 insertions(+) create mode 100644 acct-user/xrootd/metadata.xml create mode 100644 acct-user/xrootd/xrootd-0.ebuild diff --git a/acct-u

[gentoo-dev] [PATCH 1/2] acct-group/xrootd: new group for GID 469

2019-12-20 Thread Marek Szuba
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Marek Szuba --- acct-group/xrootd/metadata.xml| 8 acct-group/xrootd/xrootd-0.ebuild | 9 + 2 files changed, 17 insertions(+) create mode 100644 acct-group/xrootd/metadata.xml create mode 100644 acct-group

Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

2019-12-20 Thread Marek Szuba
On 2019-12-17 21:21, Matt Turner wrote: >> What do you think, guys? > > I don't love it. > > I don't like the mess that has become VIDEO_CARDS=... either. radeon > vs radeonsi vs amdgpu. [...] I hear you and very much agree, especially regarding the Radeon mess. That said, it seems what we are

[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

2019-12-16 Thread Marek Szuba
Penny for your thoughts, guys: I am thinking about splitting the video_cards_i965 condition in virtual/opencl so that NEO is pulled in by video_cards_iris instead, and I wonder if there is anything I haven't thought about. The reason why I would like to do this is that there is clear

  1   2   >