Dear everyone,
I hesitated for quite a while before making this decision, mostly due to
"if not me, who else?" considerations - but in the end, I feel the time
has come for me to hand in my OpenPGP keys and retire from Gentoo
development at the end of June.
These ~8 years have been a very in
Dear everyone,
After over a decade of standing behind Connman, I have in recent months
come to the conclusion that there are now better (or at least
better-documented) network-management solutions available for all of my
use cases. As a result, I no longer use net-misc/connman-gtk .
This is
On 2024-02-27 14:45, Michał Górny wrote:
In my opinion, at this point the only reasonable course of action
would be to safely ban "AI"-backed contribution entirely. In other
words, explicitly forbid people from using ChatGPT, Bard, GitHub
Copilot, and so on, to create ebuilds, code, documentati
On 2023-10-26 04:41, Eli Schwartz wrote:
This is of course either untrue or every kind of over-reaction, and
users have commented there to the effect of being willing to help
sort things out but there has been radio silence.
...which, sadly, has been my _overall_ experience with G'MIC upstrea
On 2023-10-26 02:29, Jonas Stein wrote:
this is a very powerful package with many users.
...but sadly, very few maintainers. It was m-n when I took it over 3
years ago, as apparently no-one found it worth looking after following
the disbanding of the Graphics project - and that was back when
Currently last-rited but since it seems there is interest in keeping it
in the tree, I have just returned it to the state in which it was before
I took over its maintenance 3 years ago (i.e. m-n). To anyone willing to
put up with the updates of the megapatch, the regularly emerging QA
issues an
Upstream uses a massive home-made Makefile which has since the beginning
required massive amounts of patching to make it behave reasonably
(as well as to fix the problems which ostensibly led upstream to
abandoning CMake, and which they immediately re-introduced in their NIH
solution) and which if
Signed-off-by: Marek Szuba
---
metadata/stabilization-groups/ansible | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 metadata/stabilization-groups/ansible
diff --git a/metadata/stabilization-groups/ansible
b/metadata/stabilization-groups/ansible
new file mode 100644
index
This is very much for future reference, seeing as stabilisation groups
are still very much work in progress. Anyway, the point here is to make
it easier to avoid in the future the fairly regular occurrence of
Portage complaining about having to hold back newly stabilised Ansible
Core owing to versi
In light of the current (proxied) maintainer having stated they no
longer have a Linux desktop and therefore expect difficulties in
continuing to maintain their packages,
media-gfx/rawtherapee
and
media-libs/libiptcdata
are now up for grabs. Both are up to date in the tree. They have also
g
On 2023-02-06 15:57, Michał Górny wrote:
Given there's only a handful of revdeps, perhaps you could simply test
them?
I can and have in fact already begun, starting with packages affected by
IUSE changes. Can't hurt to let maintainers know, though!
--
Marecki
OpenPGP_signature
Descriptio
Dear everyone,
Having not been given any love for a long time, we have now got in the
tree a version of dev-libs/msgpack newer than 3.3.0 - namely 5.0.0. Yes,
we have managed to skip the entire major version 4 (yay?)! Anyway, the
version in question introduces at least two breaking changes:
# Upstream keeps the module files unversioned so it is only the use of
# mirroring that has prevented us from seeing regular hash mismatches
# - and it is not clear for many of the modules whether we are allowed
# to mirror them or not. A convoluted and fragile process has been
# required to detec
No releases since 2003 (!), upstream effectively dead, no Unicode
support, EAPI 6. Removal in 30 days (#884429)
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Dear everyone,
I really could use a hand with app-admin/ansible-lint. Not that it is
exactly complicated to maintain, quite the opposite - it's just that
upstream has adopted a rather rapid release cycle and now it feels that
as soon as I have tested and pushed an ebuild for a version, another
On 2022-09-07 17:36, John Helmert III wrote:
If you find a security issue, please file a security bug. I'm not
really sure what the security impact of this is, though.
I'm not sure if this is a security issue per se (which is why I
described it as security-related), here - the default configu
On 2022-09-07 17:29, Mike Gilbert wrote:
A virtual seems a bit pointless for the following reasons:
[...]
> 2. dbus-broker[launcher] utilizes config files installed by dbus, and
> actually RDEPENDs on sys-apps/dbus for that reason.
Yeah, I failed at reading - even the README of dbus-broker cle
Dear everyone,
I wonder if we should create a virtual package to allow our users - or
at least those who run systemd anyway - to choose between sys-apps/dbus
and sys-apps/dbus-broken as D-Bus implementation for their systems. The
usual "Gentoo is about choice" thing aside, there is now at leas
On 2022-08-31 17:27, Mike Gilbert wrote:
The only pain point I see is for users with /usr on a separate
filesystem and that are not using an appropriate initramfs.
As mentioned on IRC earlier on today, another (although this would be
less of a pain point and more of a sneaky changes to run-ti
On 2022-07-25 15:35, Peter Stuge wrote:
Mikhail Koliada wrote:
This idea has been fluctuating in my head for quite a while given
that the migration had happened a while ago [0] and some other
major distributions have already adopted yescrypt as their default algo
by now [1].
Please only do th
A GNOME 2-era library with no consumers left in the tree, marked
as deprecated since March 2022. Removal in 30 days (Bug #855299).
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2022-06-29 08:35, Sam James wrote:
dev-libs/libxmlb
dev-libs/libjcat
sys-apps/fwupd
sys-apps/fwupd-efi
sys-libs/libblockdev
sys-libs/libsmbios
This is the fwupd stack.
I'm tempted for these but I only have one machine which uses them.
I'll see if anyone else is a better set of hands first
On 2022-06-29 08:15, Joonas Niilola wrote:
acct-group/lightdm
acct-user/lightdm
app-admin/keepassxc
mail-mta/msmtp
sys-apps/gptfdisk
sys-apps/lm-sensors
sys-fs/ddrescue
x11-misc/lightdm
x11-misc/lightdm-gtk-greeter
I'll take these.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital s
On 2022-06-05 09:28, Joonas Niilola wrote:
sys-process/incron
I'll take this one, with Infra as fallback maintainers.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Signed-off-by: Marek Szuba
---
.../2022-05-20-borgmatic-config-changes.en.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644
2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt
diff --git
a/2022-05-20-borgmatic-config-changes/2022-05
A couple of breaking changes have been introduced in borgmatic-1.6.0.
Only some borgmatic users will be affected but seeing as it is a backup
tool, I feel it does warrant a news item.
--
Marecki
On 2022-04-06 19:34, Rich Freeman wrote:
This is one of those low cost, low risk, high reward situations IMO.
*puts on Council hat*
The above pretty much covers my own opinion on the subject.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Signed-off-by: Marek Szuba
---
...2022-03-01-singularity_to_apptainer.en.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644
2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt
diff --git
a/2022-03-01-singularity_to_apptainer/2022-03
Dear everyone,
This should be a fairly straightforward thing for the users to do but
since manual intervention IS necessary, let us have a news item about
it! The date is a placeholder because apptainer upstream has not
released 1.0.0 yet, that said I want to have the news item ready for
publicati
On 13 December 2021 17:24:18 UTC, Mart Raudsepp wrote:
>Actually I kind of preferred a static name over straight mktemp,
>because emktemp supported other cases than a pure mktemp usage does.
>But I don't know if it could ever clash things in some weird
>situations.
That last part is the messa
On 24 December 2021 08:48:08 UTC, Pacho Ramos wrote:
>> > I think “secret” may be too generic and “libsecret” is not ideal in case
>> > an implemention comes along that is named differently. How about
>> > “secret-service”?
>>
>> I think this is a good idea.
>>
>
>And "keyring"? I am not sur
On 24 December 2021 08:48:08 UTC, Pacho Ramos wrote:
>> > I think “secret” may be too generic and “libsecret” is not ideal in case
>> > an implemention comes along that is named differently. How about
>> > “secret-service”?
>>
>> I think this is a good idea.
>>
>
>And "keyring"? I am not sur
On 2021-12-09 15:04, Michał Górny wrote:
Why do you need to use random name in the first place? We have full
control over T, so why not just hardcode a good name?
Having discussed the matter with eclass maintainers on IRC, they are not
entirely sure whether using a static name in this contex
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index c6d93a46bfe..0414d5cd5f3 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -4,7 +4,7 @@
# @ECLASS: gnome2
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 4b7c3acac06..c6d93a46bfe 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -21,14 +21,14
No longer available for EAPI-8+, and gnome2_src_prepare already calls
xdg_environment_reset via gnome2_environment_reset. All that function
did otherwise was call default src_prepare for EAPI-6+ so do just that
directly.
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file
Trivial now that emktemp is gone.
While at it, include eclass name in the "EAPI x not supported" error
message.
Signed-off-by: Marek Szuba
---
eclass/gnome2-utils.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/ecl
Has been deprecated for quite a while now, comes from eutils.eclass
so it blocks EAPI 8+. Just call mktemp directly.
Signed-off-by: Marek Szuba
---
eclass/gnome2-utils.eclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2
EHLO,
Unless I have messed something up these are all the changes required
to make these two eclasses support EAPI 8. Comments welcome!
Nb. I am not the official maintainer of these eclasses, that said I did
discuss working on updating them for EAPI 8 with leio on IRC.
--
Marecki
# Marek Szuba (2021-11-27)
# XXV has been outdated and unmaintained in Gentoo for years.
# EAPI 5, numerous QA violations.
# Removal in 30 days. Bug #TBA (Bugzilla is down)
www-misc/xxv
x11-themes/xxv-skins
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Marek Szuba (2021-11-27)
# No activity in upstream GitHub repository since July 2013,
# no official release tarballs, unmaintained in Gentoo, EAPI 5.
# Removal in 30 days. Bug #TBA (Bugzilla is down)
www-apache/mod_vhost_ldap
--
Marecki
OpenPGP_signature
Description: OpenPGP digital
On 2021-11-27 15:32, Marek Szuba wrote:
# Upstream Web site (including release tarballs) is gone, no activity
# in their GitHub repository since June 2021.
To avoid confusion, that should have said "2012". Oops.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Marek Szuba (2021-11-27)
# Upstream Web site (including release tarballs) is gone, no activity
# in their GitHub repository since June 2021. Unmaintained in Gentoo
# for years, EAPI 5.
# Removal in 30 days. Bug #TBA (Bugzilla is down)
www-apache/mod_ldap_userdir
--
Marecki
# Marek Szuba (2021-11-27)
# Upstream is long gone, unmaintained in Gentoo for years, EAPI 5.
# Removal in 30 days. Bug #TBA (Bugzilla is down)
www-apache/mod_extract_forwarded
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# No upstream activity since October 2005, release tarballs
# not available any more. Unmaintained in Gentoo, EAPI 5.
# Removal in 30 days. Bug #TBA (Bugzilla is down)
www-apache/mod_evasive
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Upstream discontinued Linux support over 10 years ago so we are now
# one major version and countless known bugs behind. No source archives
# published for current versions. Unmaintained in Gentoo for years,
# EAPI 5. Removal in 30 days. Bug #827522
sci-biology/ApE
--
Marecki
OpenPGP_signatur
# Ancient, very few distributions still package it. Both upstream
# and the Debian package we use in SRC_URI are now gone. EAPI 5,
# unmaintained in Gentoo.
# Removal in 30 days. Bug #827322
net-misc/netkit-routed
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Upstream is gone. Unmaintained in Gentoo, last updated
# back in the CVS era, EAPI 5, open bugs.
# Removal in 30 days. Bug #826790
net-analyzer/nagios-check_pidfile
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Upstream is gone. Unmaintained in Gentoo, last updated
# back in the CVS era, EAPI 5, open bugs.
# Removal in 30 days. Bug #826786
net-analyzer/nagios-check_fail2ban
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-11-25 04:49, Mike Gilbert wrote:
Also, I don't think it is relevant to call out the mistake by the QA
team in a news item intended for end users.
My sentiment exactly. No finger pointing in news items, please.
I don't like the phrase "forcefully downgraded" here. This implies
that so
# No new releases since July 2013, no commits to upstream Git repository
# since May 2019, long list of known issues (including Bug #681520),
# unmaintained in Gentoo, EAPI 5. Consider using dev-util/uglifyjs
# instead.
# Removal in 30 days. Bug #826470
dev-util/yuicompressor
--
Marecki
OpenPGP
# Last release in 2009, dead upstream. Rendered obsolete by native PDF
# importers provided by LibreOffice/OpenOffice, which actually read PDFs
# instead of converting them to images. Unmaintained in Gentoo, EAPI 5.
# Removal in 30 days. Bug #826382
app-text/pdf2oo
--
Marecki
OpenPGP_signature
No releases or repo activity upstream since 2013, both versions
currently in the tree fail to build (for different reasons),
unmaintained in Gentoo, stable ebuild uses EAPI 5.
Removal in 30 days. Bug #756925
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
# Upstream switched from static documentation to the Wiki format
# around 10 years ago, and the ebuild we've got in the tree was
# massively outdated even then (our version: 812, last static
# upstream version: 2001). No maintainer in Gentoo, EAPI 5.
# Removal in 30 days. Bug #826454
app-doc/selfh
Last release in 2008 at the latest, no maintainer in Gentoo for years,
EAPI 5, upstream is gone, the only distros which still package it are
Gentoo, Funtoo and LiGurOS.
Removal in 30 days. Bug #826682
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Sorry about a long delay responding, I ended up being offline until the
end of last week and I've had quite a lot of catching up.
Anyway, let me begin by addressing a sentiment expressed independently
in several responses and which could be summarised as "just come and
help". A laudable idea i
Dear everyone,
Following some private discussions, I feel quite strongly now that it
would both considerably improve certain processes and make our use of
limited manpower more efficient were we to further reduce the number of
stable arches in Gentoo Linux. Specifically, I propose to drop
-
On 2021-10-05 05:04, Sam James wrote:
Hi all,
Chainsaw asked retirement@ to drop him to maintainer-needed on his packages, so
here's the resultant
packages with no maintainers left:
app-admin/ansible-lint
> dev-python/requests-credssp
I'll take these.
--
Marecki
OpenPGP_signature
Des
On 2021-09-26 21:20, Rich Freeman wrote:
Back in the PGP ITAR days I believe somebody went through some
loopholes to publish the software outside the US,
Yes, PGP 2.6 source code got published as an OCR-friendly book
(https://dl.acm.org/doi/book/10./207390) which was then legally
taken f
On 2021-09-02 11:46, Michał Górny wrote:
lua.eclass: Set @PROVIDES
lua-single.eclass: Set @PROVIDES
ACK on these two.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-08-16 18:31, Andreas Sturmlechner wrote:
Feel free to pick up task no. 3 from the bug. Everything else is either done
already or easy enough.
OK, I'll see what I can do.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-08-16 17:50, Joonas Niilola wrote:
It'd help if you described the caveats that are to be expected.
I would say there are two:
1. Apart from from what comes out on the latest even branch (I would
strongly advise against packaging odd branches if you value your sanity,
except possibly
On 2021-08-16 18:06, Joonas Niilola wrote:
What's the rush with 8 anyway? We still have eclasses that don't even
support 7. And since 6 is now, sigh, deprecated, any bump to ebuilds
depending on those eclasses will add to the evergrowing CI issue list
right? I'd say it's more important to secure
On 2021-08-16 17:49, Sam James wrote:
See https://bugs.gentoo.org/802786 and https://github.com/gentoo/kde/pull/903.
There's some work to be done first.
I see. Guess we'll have to stick with EAPI 7 for cmake revdeps in the
foreseeable future, then.
--
MS
OpenPGP_signature
Description: O
smallest possible changes to get it to work with EAPI 8 (i.e. no removal
of banned functions etc.) - and fortunately it seems extending the $EAPI
check is all that is needed.
Would be great if someone from kde@g.o. could give their blessing (or
lack thereof) to this patch.
On 2021-08-16 17:43, M
Signed-off-by: Marek Szuba
---
eclass/cmake.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..52bf65a463d 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -9,7 +9,7 @@
# Maciej Mrozowski
On 2021-08-16 16:22, Lars Wendler wrote:
thank you very much for wqriting this up. I highly appreciate this.
Cheers!
echo 'app-misc/mc' >> /etc/portage/package.use
I suppose that should be:
echo 'app-misc/mc xdg' >> /etc/portage/package.use
Indeed. Fixed locally.
and have ever
Title: >=app-misc/mc-4.8.27 to drop support for ~/.mc
Author: Marek Szuba
Posted: 2021-08-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-misc/mc
app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look
for their user configuration in two possible places:
* if bu
Hi all,
I'm taking a (hopefully temporary) break from maintaining
net-libs/nodejs, as I expected when took it on it is a relatively
high-intensity package and I fear that if I keep it up at this rate I'll
end up burning out as a Gentoo developer. Anyone interested in stepping
in? Node has sti
On 2021-08-10 06:17, Mikle Kolyada wrote:
I will take those as yubikey is my daily use now
And I'll co-maintain them, both for the same reason as zlogene and
because I maintain two YubiKey-related packages (as well as one for
SoloKeys which depends on fido2) already.
--
Marecki
OpenPGP_
Dear everyone,
During the open-floor part of this month's Council meeting I asked
whether there is any official policy regarding what is or is not
guaranteed for hardware architectures we do not consider stable in
Gentoo. For reference, according to the current version of
profiles/arches.desc
This is so that lua_gen_foo() calls die on mentions of formerly
supported implementations, allowing for such mentions to be gradually
removed from ebuilds which contain them.
Signed-off-by: Marek Szuba
---
eclass/lua-single.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Similarly to _PYTHON_HISTORICAL_IMPLS, it will hold names of Lua
implementations which used to be supported but no longer are.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
If memory serves me right there _are_ ebuilds which mention lua5-2 in
lua_gen_cond_dep() calls. Let's steal another idea from Python eclasses
and allow this implementation not to trip pattern validation in spite of
no longer being supported by the eclasses, by be declaring it a
historical implement
On 2021-07-16 22:50, Sam James wrote:
But to introduce a fix, isn't it a _lot_ easier to do it at the point of a new
EAPI?
In general, IMHO only if we intend to preserve the old (incorrect)
behaviour for older EAPIs - which in this particular case was not needed
because I cannot think of so
the
target arch, necessitating the use of both DEPEND and BDEPEND on newer
EAPIs.
Closes: https://bugs.gentoo.org/802153
Signed-off-by: Marek Szuba
---
eclass/fortran-2.eclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/eclass/fortran-2.eclass b/eclass/fortra
With many thanks to ulm for having pointed this out. Not that while this
patch does indeed change the eclass behaviour for the established EAPI 7
rather than for the new EAPI 8, it does so in a way I deem non-intrusive
enough to allow this - the only case where something is actually removed
from DE
On 2021-07-15 06:58, Ulrich Mueller wrote:
In the latest bunch of updates, we have changed many eclasses to have
only a single error case, and also standardized the die message.
Maybe simplify this eclass as well?
If anyone from Sci suggests/seconds this I shall not argue, that said I
do in f
Signed-off-by: Marek Szuba
---
eclass/cuda.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index b1da77c69dd..08d2302d55b 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,11 +1,11 @@
-# Copyright 1999-2020
Like fortran-2 adding support for EAPI 8 appears to be trivial, unlike
fortran-2 we have no longer got any deprecated-EAPI ebuilds in the tree
inheriting it.
On 2021-07-14 13:02, Ulrich Mueller wrote:
Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8?
Good point! I've created https://bugs.gentoo.org/802153 so that we do
not lose track of this, that said it is beyond the scope of the issue at
hand (the eclass will not behave any different
On 2021-07-13 18:54, Michał Górny wrote:
+media-sound/easyeffects is already available in the tree, and the
+remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will
s/ebuilds/versions/.
Changed locally.
+be removed in 7 days.
Probably better to use an explicit date here. '
On 2021-07-13 18:35, William Hubbs wrote:
>> are there any non-cosmetic reasons for doing this?
Consistency with the rest of the tree. If you do a "git grep _R0" on the
eclass directory, the lua eclasses are the only ones that have this in
the names of the guard variables, and the eclasses the
Signed-off-by: Marek Szuba
---
eclass/fortran-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 0bb00f475a2..9d0c71703e4 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -7,7 +7,7
On the plus side, nothing in here that requires changing to work with
the new EAPI. On the minus side, we still got many EAPI-5 and 6
consumers of this eclass in the tree so no chance of dropping support
for these two at this time.
Signed-off-by: Marek Szuba
---
...2021-07-16-pulseeffects-easyeffects.en.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt
diff --git
a/2021-07-16-pulseeffects-easyeffects/2021-07
New version incorporating suggestions from mgorny and ulm, thank you for
your feedback.
--
Marecki
On 2021-07-13 07:20, Michał Górny wrote:
Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
The title is too long (50 chars max AFAIR)
Argh, and after all my attempts to keep this as short as possible while
keeping this meaningful :-) Will think of something even short
On 2021-07-13 01:01, Marek Szuba wrote:
Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
Author: Marek Szuba
Posted: 2021-07-16
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=media-sound/pulseeffects-5.0.0
In response to the upstream decision to ren
fter the ebuild is gone,
won't it.
* * *
Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
Author: Marek Szuba
Posted: 2021-07-16
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=media-sound/pulseeffects-5.0.0
In response to the upstream decision to rename
# Marek Szuba (2021-07-12)
# No releases since March 2015, no upstream repo activity since November
# 2019. Unmaintained in Gentoo. Depends on effectively EOLed Lua 5.2,
# fails to build against any other version. Removal in 30 days
# (Bug #801883)
app-crypt/cardpeek
--
Marecki
On 2021-07-09 17:34, William Hubbs wrote:
Actually upstream does say when they will stop supporting each version
[1].
Um, where? Because I've looked at this page before, I've looked at it
again just now and I all can see there is that there will be no further
releases of Lua versions up to and
On 2021-07-11 21:54, Michał Górny wrote:
My gut feeling is that having this distinction is useful. However, it
has been pointed out that we've probably never really had to use it
(i.e. use the "banned" argument to stop someone from using old EAPI)
and that the switch from "deprecated" to "banne
On 2021-07-10 22:55, William Hubbs wrote:
Change the _R0 suffix on these variable names to _ECLASS.
Since my question in response to the previous round of this has yet to
be answered, I repeat: are there any non-cosmetic reasons for doing this?
--
Marecki
OpenPGP_signature
Description: O
On 2021-07-09 15:35, William Hubbs wrote:
As many (if not most) of you know, the Lua ecosystem is somewhat awkward
owing to the facts that on the one hand dev-lang/lua upstream has never
officially declared end of life on older versions,
Actually upstream does say when they will stop supportin
Dear everyone,
As many (if not most) of you know, the Lua ecosystem is somewhat awkward
owing to the facts that on the one hand dev-lang/lua upstream has never
officially declared end of life on older versions, and on the other
dev-lang/luajit has never moved beyond 5.1 with their API support.
On 2021-07-06 22:59, William Hubbs wrote:
Change the _R0 suffix on these variable names to _ECLASS.
Any non-cosmetic reasons for doing this?
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-07-02 10:12, Sergei Trofimovich wrote:
app-misc/mc
dev-util/ltrace
media-fonts/terminus-font
media-libs/aalib
Will attach myself to these four.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-07-02 08:41, Sergei Trofimovich wrote:
# fuzzer tools of sorts, very fun ones:
app-forensics/honggfuzz
sys-libs/blocksruntime
app-forensics/radamsa
app-forensics/zzuf
I'll take the lot.
# maybe retire? it somewhat worked a while ago
x11-plugins/purple-mattermost
Seconding reti
On 2021-06-22 10:35, Marek Szuba wrote:
Seeing as in the end this USE flag is not going anywhere in spite of
Gentoo no longer providing PaX-capable kernel sources, could we please
rename it (e.g. to 'pax-kernel') so that it no longer contains a
disallowed character.
Done. Now th
1 - 100 of 287 matches
Mail list logo
