[gentoo-dev] Packages up for grabs per ikelos's retirement
Hey, the following packages are now up for grabs: app-crypt/ophcrack app-crypt/ophcrack-tables app-crypt/ssdeep app-crypt/xca app-forensics/foremost dev-libs/libnfc dev-python/mypy_extensions net-analyzer/nipper net-libs/libnipper pkgcheck reports: app-crypt/ophcrack-tables DeprecatedEapi: version 1.0-r2: uses deprecated EAPI 5 net-analyzer/nipper DeprecatedEapi: version 0.12.0: uses deprecated EAPI 6 DeprecatedEclass: version 0.12.0: uses deprecated eclass: cmake-utils (migrate to cmake.eclass) net-libs/libnipper DeprecatedEapi: version 0.12.6-r1: uses deprecated EAPI 6 DeprecatedEclass: version 0.12.6-r1: uses deprecated eclass: cmake-utils (migrate to cmake.eclass) app-crypt/xca StableRequest: version 2.3.0-r1: slot(0) no change in 53 days for unstable keywords: [ ~amd64, ~ppc, ~x86 ] ophcrack and xca have bugs open. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Multiple packages up for grabs
I will take those as yubikey is my daily use now 10 августа 2021 г. 03:30:33 GMT+03:00, Gokturk Yuksek пишет: >The following packages are up for grabs: > > app-crypt/libu2f-host > app-crypt/libu2f-server > app-crypt/yubikey-manager > dev-python/fido2 > dev-python/pyotherside > sys-auth/libyubikey > sys-auth/ykpers > >Thanks, > >-- >gokturk > -- Простите за краткость, создано в K-9 Mail.
[gentoo-dev] Multiple packages up for grabs
The following packages are up for grabs: app-crypt/libu2f-host app-crypt/libu2f-server app-crypt/yubikey-manager dev-python/fido2 dev-python/pyotherside sys-auth/libyubikey sys-auth/ykpers Thanks, -- gokturk OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-dialup/xc
# Joshua Kinard (2021-08-09) # Dead upstream and has build issues in modern times. # See bugs #551786 and #715846. Removal in 30 days. net-dialup/xc
[gentoo-dev] [PATCH v3 2/2] xdg.eclass: drop support for EAPI 4
Signed-off-by: Florian Schmaus
---
eclass/xdg.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/xdg.eclass b/eclass/xdg.eclass
index d973a09c29d9..80d291a7de5b 100644
--- a/eclass/xdg.eclass
+++ b/eclass/xdg.eclass
@@ -6,7 +6,7 @@
# freedesktop-b...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue
-# @SUPPORTED_EAPIS: 4 5 6 7 8
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Provides phases for XDG compliant packages.
# @DESCRIPTION:
# Utility eclass to update the desktop, icon and shared mime info as laid
@@ -16,7 +16,7 @@ inherit xdg-utils
_DEFINE_XDG_SRC_PREPARE=false
case "${EAPI}" in
- 4|5|6|7)
+ 5|6|7)
# src_prepare is only exported in EAPI < 8.
EXPORT_FUNCTIONS src_prepare
_DEFINE_XDG_SRC_PREPARE=true
@@ -35,7 +35,7 @@ _XDG_DEPEND="
"
case "${EAPI}" in
- 4|5|6|7)
+ 5|6|7)
DEPEND="${_XDG_DEPEND}"
;;
*)
--
2.31.1
[gentoo-dev] [PATCH v3 1/2] xdg.eclass: add EAPI 8 support
Note that this removes the export of src_prepare in EPAI 8 as
requested by ionen:
1. remove src_prepare export in EAPI-8
While "some" packages need xdg_environment_reset, most don't because
the eclass is often only inherited to handle icons/.desktop and this
just needlessly overwrite the src_prepare of other eclasses requiring
more careful inherit ordering (e.g. inherit xdg cmake).
I'd prefer it was clear when a package need this by calling
xdg_environment_reset directly. Unless there is a non-trivial amount
of packages that need it (e.g. for tests) that I'm not aware of.
Thanks to ulm and others for providing feedback.
Signed-off-by: Florian Schmaus
---
eclass/xdg.eclass | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/eclass/xdg.eclass b/eclass/xdg.eclass
index 219be712e84d..d973a09c29d9 100644
--- a/eclass/xdg.eclass
+++ b/eclass/xdg.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: xdg.eclass
@@ -6,7 +6,7 @@
# freedesktop-b...@gentoo.org
# @AUTHOR:
# Original author: Gilles Dartiguelongue
-# @SUPPORTED_EAPIS: 4 5 6 7
+# @SUPPORTED_EAPIS: 4 5 6 7 8
# @BLURB: Provides phases for XDG compliant packages.
# @DESCRIPTION:
# Utility eclass to update the desktop, icon and shared mime info as laid
@@ -14,29 +14,47 @@
inherit xdg-utils
-case "${EAPI:-0}" in
+_DEFINE_XDG_SRC_PREPARE=false
+case "${EAPI}" in
4|5|6|7)
- EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst pkg_postrm
+ # src_prepare is only exported in EAPI < 8.
+ EXPORT_FUNCTIONS src_prepare
+ _DEFINE_XDG_SRC_PREPARE=true
;;
- *) die "EAPI=${EAPI} is not supported" ;;
+ 8)
+ ;;
+ *) die "${ECLASS}: EAPI=${EAPI} is not supported" ;;
esac
+EXPORT_FUNCTIONS pkg_preinst pkg_postinst pkg_postrm
# Avoid dependency loop as both depend on glib-2
if [[ ${CATEGORY}/${P} != dev-libs/glib-2.* ]] ; then
-DEPEND="
+_XDG_DEPEND="
dev-util/desktop-file-utils
x11-misc/shared-mime-info
"
+
+case "${EAPI}" in
+ 4|5|6|7)
+ DEPEND="${_XDG_DEPEND}"
+ ;;
+ *)
+ IDEPEND="${_XDG_DEPEND}"
+ ;;
+esac
fi
+if ${_DEFINE_XDG_SRC_PREPARE}; then
# @FUNCTION: xdg_src_prepare
# @DESCRIPTION:
# Prepare sources to work with XDG standards.
+# Note that this function is only defined and exported in EAPIs < 8.
xdg_src_prepare() {
xdg_environment_reset
[[ ${EAPI:-0} != [45] ]] && default
}
+fi
# @FUNCTION: xdg_pkg_preinst
# @DESCRIPTION:
--
2.31.1
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On 2021-08-08 13:17, David Seifert wrote:
So you've created a big commotion... because you didn't get the initial
point? Honestly, this seems to be a recurring theme at this point.
Someone suggests some improved check/some change, and nowadays you can
bet 50 quid that Whissi will pop up and bikeshed it in some way.
No?
First of all, just because you disagree with something or believe a
discussion is wrong and or not necessary and start to frame it as
bikeshedding, it doesn't actually become bikeshedding. This is a very
sad and transparent attempt to silence people through defamation.
The draft contains an error. It's saying that "/etc/tmpfiles.d" became
deprecated which is not true. Because this would imply that it was
previously acceptable for packages in Gentoo repository to install to
that location which is not correct. If a packages in ::gentoo installed
to /etc/tmpfiles.d before, this was already wrong.
And my point was and still is, that neither the commit message nor the
eqawarn should use the wording "deprecated" because nothing has changed
-- no location became deprecated.
And this will also address parts of antarus' previous mail: Because this
QA check should be only about ::gentoo repository, this shouldn't affect
any other repository. I.e. in your own overlay, you are free to do
whatever you want and can't be forced to stick to Gentoo QA rules.
It's become a real problem at this point. In fact, we have proxy
maintainers publicly refusing to work on packages somehow involving you
(I'll mention no names, but check the #-desktop backlog), because your
personality boils down to three attributes nowadays:
I am not in that channel and never was. If you make such an allegation,
include facts so that I can respond. If you look at my complete history
at GitHub issues you will find that most people I worked with
appreciated to work with me. Of course there are some bugs/PRs where I
rejected a requested change but I am not sure what your point is. This
is normal because not every PR is valid.
1. If I say the sky is blue, you'll say it's green. If I say it's green,
you'll say it's blue. I've had at least 5 people tell me they see the
exact same pattern in you (and no, mgorny is not part of that set,
before you throw that point at me). You're the textbook contrarian of
Gentoo ("Wutbürger") right now.
2. You'll tell people they are wrong, they aren't following protocols,
they made a mistake, but you will never follow through with actually
telling people what/why or how. By the time people ask you "why?",
you've already disappeared. Given how frequently this happens in
multiple channels, projects and at different time points, statistically,
this can't be explained by coincidence any more. This happens
practically on a daily basis, so you're not getting the benefit of the
doubt any more.
3. You can't let go. The security elections disaster right now is the
prime example (yes, it's public, just check the history of the Security
Project). This captures you so well: it's all about **community** and
stuff, until you lose, then you start invoking technicalities and
procedural shenanigans to justify some ludicrous kind of "co-lead" crap.
Frankly, it's embarrassing, and you're at the centre of it. Instead of
accepting defeat (remember, community and democracy!), you just fudge
the results.
Interesting. You don't even now my view on this but you already have an
opinion and are saying that I am the culprit. I think this is called
"prejudiced". I am pretty sure that as a ComRel member you will abstain
from this case as you seem to be superior. I mean you are publicly
attacking me for 10+ months, rejected any attempt from my side when I
tried to speak with you to get things sorted and now you showed how
biased your are...
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-perl/Goo-Canvas and x11-libs/goocanvas:0
# Andreas Sturmlechner (2021-08-09) # EAPI-5, dead, unused; bug #776403. Removal on 2021-09-08. dev-perl/Goo-Canvas x11-libs/goocanvas:0 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Election Officials Wanted
Ladies and Gentlemen The elections project is looking for two officials to conduct the count for the base-system project lead position. Nominations are already complete and the infra contact is setting up the election. Voting is expected to last seven days, starting soon, so if you will be around for the count and have shell access to Woodpecker you are qualified. Candidates in the election need not apply. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgp3adNZDH64p.pgp Description: PGP signature
