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
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 chang
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
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
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 hav
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
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 t
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-
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 bl
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
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
inux 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 +++
.../nv
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
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
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
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. T
# 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
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
+# @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
@@ -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
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
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 wit
n 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-
# 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
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 her
On 2020-07-29 12:10, Michał Górny wrote:
> LGTM. Thanks!
Okay then, merged!
--
MS
signature.asc
Description: OpenPGP digital signature
# 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
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
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
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 ye
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]}" \
> + "${DES
# 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
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 mgor
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
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
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
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
Merged, thank you everyone who has weighed in with their comments both
on IRC and here.
--
MS
signature.asc
Description: OpenPGP digital signature
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
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.
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
LLV
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 mu
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
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
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
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
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
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
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
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
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
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 bloc
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
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
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 d
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
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
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
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_s
# 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
--
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-sin
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
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.
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
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
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
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
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 of
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.
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
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-mis
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 of
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 cover
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 migh
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
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 kee
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, s
# 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
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 muc
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
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
Op
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
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 t
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
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 likel
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
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
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
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 improv
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 ebui
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,
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
On 17/01/2021 09:26, Michał Górny wrote:
[bv] x11-plugins/vicious
[B ] x11-wm/awesome
I'll take these two.
--
MS
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 mak
On 22/01/2021 14:38, Marek Szuba wrote:
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
On 05/03/2021 19:37, Sam James wrote:
Following the retirement of a proxy maintainer, as their request, we have the
following packages up for grabs:
app-emulation/fuse
app-emulation/fuse-utils
app-emulation/libspectrum
I'll take them.
--
Marecki
# Depends on bundled out-of-date Qt5 libraries, and even with those
# installed recent upstream versions fail to run. Moreover, we have now
# got a source variant in the tree which, while still CLI-only for now,
# is up to date and actually works.
# Removal in 30 days. Bug #768228.
mail-mta/prot
On 2021-03-29 10:06, James Le Cuirot wrote:
Have you seen CONFIG_CMDLINE? It lets you bake command line args into
the kernel image itself.
And since 5.6, there is also bootconfig:
https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html
--
MS
OpenPGP_signature
Description: OpenP
On 2021-03-27 23:40, Joshua Kinard wrote:
The MIPS machine has functioning local disk drives, and currently, it
boots fine by just pulling a kernel off my TFTP server and booting
from the local drive, no initramfs needed because I compiled
everything into it.
Out of curiosity, if your kernel i
Title: x86 support to be dropped from media-gfx/darktable
Author: Marek Szuba
Posted: 2021-05-15
Revision: 1
News-Item-Format: 2.0
Display-If-Keyword: x86
Display-If-Installed: =media-gfx/darktable-2.6.2
Since version 3.0.0 media-gfx/darktable officially only supports 64-bit
architectures, and
101 - 200 of 287 matches
Mail list logo
