On 2021-05-12 09:53, William Breathitt Gray wrote:
The following packages are up for grabs:
games-action/minetest
acct-group/minetest
acct-user/minetest
dev-cpp/benchmark
dev-cpp/prometheus-cpp
I'll take them.
--
MS
OpenPGP_signature
Description: OpenPGP digital signature
hor: Marek Szuba
Posted: 2021-05-18
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-p2p/syncthing
Starting with version 1.17.0, net-p2p/syncthing by default only allows
TLS 1.3 for sync connections - making it impossible to sync with devices
not supporting, i.e. running Syncthing versi
Dear all,
Seeing as it has been around year since we added
dev-libs/opencl-icd-loader to the tree, I wonder whether it would
perhaps make sense to make it, rather than dev-libs/ocl-icd, the
preferred OpenCL ICD loader for new installations.
Advantages (that I can see) of opencl-icd-loader:
On 2021-05-14 19:25, Ulrich Mueller wrote:
Too long, GLEP 42 allows 50 chars max after "Title: ".
OK, will change this to
Title: >=net-p2p/syncthing-1.17.0 incompatibility warning
--
MS
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-06-13 10:01, David Seifert wrote:
dev-vcs/git-flow
I'll take this one.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Signed-off-by: Marek Szuba
---
eclass/sword-module.eclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eclass/sword-module.eclass b/eclass/sword-module.eclass
index 2ae58d1e51b..f8ae83c9f05 100644
--- a/eclass/sword-module.eclass
+++ b/eclass/sword-module.eclass
Nothing special here. RESTRICT manipulation in lua-utils still uses +=
on purpose, for consistency with how other variables are handled there
as well as in order to avoid wasting CPU cycles on an EAPI version
check for something that ultimately achieves the same.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index ddf44f354e1..59959eaf9c0 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -8,7 +8,7
Signed-off-by: Marek Szuba
---
eclass/lua.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index 46d9e848c87..e3a25c5d184 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo
Signed-off-by: Marek Szuba
---
eclass/lua-single.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index 11c2790dac2..7abe1eb6674 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -1,4 +1,4
On 2021-06-16 11:22, Michał Górny wrote:
IMO it makes most sense to just switch the default to irc.gentoo.org if
we are going to change defaults anyway.
We can't really do that as ircs://irc.gentoo.org causes certificate
hostname mismatch.
On a somewhat tangential note, could we add a TLSA R
On 2021-06-16 19:18, Sam James wrote:
- app-editors/hexcurse
I'll take this one.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Dear everyone,
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. I understand the main reason this hasn't been done
On 2021-06-22 19:01, Sergei Trofimovich wrote:
One of the steps forward for libffi would be to add extra USE=pax-kernel
with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.
Sounds like a good idea to me, that way people who don't pay attention
to news items will notice.
--
Ma
# Marek Szuba (2021-06-25)
# Unslotted version conflicting with lua eclasses.
# No revdeps left. EAPI 5. Removal in 30 days (Bug #798693)
dev-lang/lua:0
--
MS
OpenPGP_signature
Description: OpenPGP digital signature
change itself, my plan is to temporarily add the
REQUIRED_USE compatibility guard to libffi (as suggested by slyfox) and
simply rename the flag everywhere else.
* * *
Title: USE flag 'pax_kernel' to be renamed to 'pax-kernel'
Author: Marek Szuba
Posted: 2021-06-28
R
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
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-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-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
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-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
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-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-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
# 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
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
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
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
New version incorporating suggestions from mgorny and ulm, thank you for
your feedback.
--
Marecki
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
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
---
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 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
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-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
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.
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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
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: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: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-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-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-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
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
-
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
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
# 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
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
# 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 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
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
# 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
# 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
# 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 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
# 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
# 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
# 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
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)
# 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
# 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
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
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
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
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
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
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
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
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 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
201 - 287 of 287 matches
Mail list logo
