Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
> On 3 Nov 2020, at 21:53, James Le Cuirot wrote: > > On Tue, 03 Nov 2020 22:32:11 +0100 > Michał Górny wrote: > >> Additionally, the following packages are looking for a new maintainer: >> >> net-misc/chrony > > I may take this if no one else really wants it. I run a simple client > and server setup on Gentoo at home but I have no interest in the fancy > features. I have some familiarity with Chrony so could we co-maintain? > >> www-client/vivaldi >> www-client/vivaldi-snapshot > > I'll take these but it may take me some time to get some kind of > automation going for the frequent bumps involved. I know that Opera is > a similar package but I really don't want it. BTW: Speak with the Chromium team as I think they’re looking at automating these all if possible (not guaranteed, ofc). > > -- > James Le Cuirot (chewi) > Gentoo Linux Developer signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Tue, 03 Nov 2020 22:32:11 +0100 Michał Górny wrote: >Hi. > >The following projects have no members right now: > >https://wiki.gentoo.org/wiki/Project:Debian_Tools > >Additionally, the following packages are looking for a new maintainer: > I'll take these: >app-admin/whowatch >net-ftp/lftp >net-misc/putty And I am interested in these as well in case nobody else takes them: >net-dns/libidn >net-dns/libidn2 >net-misc/youtube-dl >x11-libs/libvdpau >x11-misc/vdpauinfo Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpThwcHLJdTA.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
Am 03.11.2020 um 22:32 schrieb Michał Górny: app-benchmarks/nbench I will take that one. net-ftp/lftp net-misc/putty x11-terms/rxvt-unicode Anyone want's to maintain? I could imagine to help as co-maintainer. Conrad
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages & projects up for grabs due to jer's retirement
On Tue, 2020-11-03 at 22:48 +0100, Michał Górny wrote: > On Tue, 2020-11-03 at 22:32 +0100, Michał Górny wrote: > > Hi. > > > > The following projects have no members right now: > > > > https://wiki.gentoo.org/wiki/Project:Debian_Tools > > > > Additionally, the following packages are looking for a new > > maintainer: > > [...] > > Of course, missed an eclass: > > nvidia-drivers.eclass > I'll take nvidia
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Tue, 2020-11-03 at 22:32 +0100, Michał Górny wrote: > dev-libs/libevent I'll take this one. > net-dns/libidn > net-dns/libidn2 And these two. > net-libs/http-parser Plus this. > net-misc/youtube-dl Maybe this but co-maintainers appreciated. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On Tue, 03 Nov 2020 22:32:11 +0100 Michał Górny wrote: > Additionally, the following packages are looking for a new maintainer: > > net-misc/chrony I may take this if no one else really wants it. I run a simple client and server setup on Gentoo at home but I have no interest in the fancy features. > www-client/vivaldi > www-client/vivaldi-snapshot I'll take these but it may take me some time to get some kind of automation going for the frequent bumps involved. I know that Opera is a similar package but I really don't want it. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpBo6kggM2u6.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Packages & projects up for grabs due to jer's retirement
On Tue, 2020-11-03 at 22:32 +0100, Michał Górny wrote: > Hi. > > The following projects have no members right now: > > https://wiki.gentoo.org/wiki/Project:Debian_Tools > > Additionally, the following packages are looking for a new maintainer: > [...] Of course, missed an eclass: nvidia-drivers.eclass -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages & projects up for grabs due to jer's retirement
Hi. The following projects have no members right now: https://wiki.gentoo.org/wiki/Project:Debian_Tools Additionally, the following packages are looking for a new maintainer: app-admin/fam app-admin/killproc app-admin/sysstat app-admin/whowatch app-arch/mt-st app-benchmarks/nbench app-editors/sandy app-misc/cmatrix app-misc/figlet app-shells/bashish app-text/an app-text/jo app-text/pinfo app-text/teseq app-text/wscr dev-embedded/stm32flash dev-libs/cl dev-libs/dmalloc dev-libs/libconfig dev-libs/libevent dev-libs/liblinear dev-libs/libstrl dev-util/complexity dev-util/cppi dev-util/difffilter dev-util/indent dev-util/redo dev-util/rej dev-util/splint dev-vcs/cssc media-gfx/farbfeld media-gfx/fbida media-gfx/imv media-gfx/scrot media-gfx/wings media-video/blind net-dialup/wvdial net-dns/idnkit net-dns/libidn net-dns/libidn2 net-ftp/lftp net-ftp/ncftp net-libs/http-parser net-libs/nodejs net-libs/wvstreams net-misc/chrony net-misc/olsrd net-misc/putty net-misc/whatmask net-misc/youtube-dl sci-calculators/datamash sci-calculators/units sys-apps/pv sys-block/viaideinfo sys-boot/unetbootin sys-fs/fatresize sys-fs/jmtpfs sys-power/powernowd www-client/opera www-client/opera-beta www-client/opera-developer www-client/otter www-client/surf www-client/vivaldi www-client/vivaldi-snapshot x11-drivers/nvidia-drivers x11-libs/libvdpau x11-misc/sent x11-misc/sprop x11-misc/vdpauinfo x11-misc/xidle x11-misc/xkbset x11-misc/xowl x11-terms/rxvt-unicode x11-terms/st x11-terms/yeahconsole x11-wm/aewm x11-wm/goomwwm x11-wm/herbstluftwm x11-wm/musca x11-wm/ratpoison x11-wm/wmfs x11-wm/xoat -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7
On 11/3/20 11:25 AM, Marek Szuba wrote: 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. 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.
Re: [gentoo-dev] [PATCH] depend.apache.eclass: support EAPI-7
El mar, 03-11-2020 a las 17:25 +0100, Marek Szuba escribió: > 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 > @@ -1,10 +1,10 @@ > -# Copyright 1999-2012 Gentoo Foundation > +# Copyright 1999-2020 Gentoo Authors > # Distributed under the terms of the GNU General Public License v2 > > # @ECLASS: depend.apache.eclass > # @MAINTAINER: > # apache-d...@gentoo.org > -# @SUPPORTED_EAPIS: 0 2 3 4 5 6 > +# @SUPPORTED_EAPIS: 0 2 3 4 5 6 7 > # @BLURB: Functions to allow ebuilds to depend on apache > # @DESCRIPTION: > # This eclass handles depending on apache in a sane way and provides > information > @@ -44,7 +44,7 @@ case ${EAPI:-0} in > 0|2|3|4|5) > inherit multilib > ;; > - 6) > + 6|7) > ;; > *) > die "EAPI=${EAPI} is not supported by depend.apache.eclass" If I remember correctly, some important bugs were pending and affecting to eapi6... then, I guess they would also affect eapi7 https://bugs.gentoo.org/616612 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: fdo-mime.eclass
# @DEAD # No consumers left. Removal in 30 days. signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] depend.apache.eclass: support EAPI-7
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 @@ -1,10 +1,10 @@ -# Copyright 1999-2012 Gentoo Foundation +# Copyright 1999-2020 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: depend.apache.eclass # @MAINTAINER: # apache-d...@gentoo.org -# @SUPPORTED_EAPIS: 0 2 3 4 5 6 +# @SUPPORTED_EAPIS: 0 2 3 4 5 6 7 # @BLURB: Functions to allow ebuilds to depend on apache # @DESCRIPTION: # This eclass handles depending on apache in a sane way and provides information @@ -44,7 +44,7 @@ case ${EAPI:-0} in 0|2|3|4|5) inherit multilib ;; - 6) + 6|7) ;; *) die "EAPI=${EAPI} is not supported by depend.apache.eclass" -- 2.26.2
[gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7
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!
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 for the second half of October. All tickets have been opened. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2 2/2] selinux-policy-2.eclass: drop EAPI 5
Signed-off-by: David Michael --- Changes since v1: - Dropped unnecessary EAPI default value - Fixed eapply array awareness eclass/selinux-policy-2.eclass | 47 +- 1 file changed, 12 insertions(+), 35 deletions(-) diff --git a/eclass/selinux-policy-2.eclass b/eclass/selinux-policy-2.eclass index 3ba310e49de..5def86fbef9 100644 --- a/eclass/selinux-policy-2.eclass +++ b/eclass/selinux-policy-2.eclass @@ -7,7 +7,7 @@ # @ECLASS: selinux-policy-2.eclass # @MAINTAINER: # seli...@gentoo.org -# @SUPPORTED_EAPIS: 5 6 7 +# @SUPPORTED_EAPIS: 6 7 # @BLURB: This eclass supports the deployment of the various SELinux modules in sec-policy # @DESCRIPTION: # The selinux-policy-2.eclass supports deployment of the various SELinux modules @@ -75,8 +75,8 @@ : ${SELINUX_GIT_BRANCH:="master"}; case "${EAPI:-0}" in - 0|1|2|3|4) die "EAPI<5 is not supported";; - 5|6|7) : ;; + 0|1|2|3|4|5) die "EAPI<6 is not supported";; + 6|7) : ;; *) die "unknown EAPI" ;; esac @@ -87,10 +87,6 @@ case ${BASEPOL} in EGIT_CHECKOUT_DIR="${WORKDIR}/refpolicy";; esac -if [[ ${EAPI:-0} == 5 ]]; then - inherit eutils -fi - IUSE="" HOMEPAGE="https://wiki.gentoo.org/wiki/Project:SELinux; @@ -117,7 +113,7 @@ else RDEPEND=">=sys-apps/policycoreutils-2.0.82 >=sec-policy/selinux-base-policy-${PV}" fi -if [[ ${EAPI:-0} == [56] ]]; then +if [[ ${EAPI} == 6 ]]; then DEPEND="${RDEPEND} sys-devel/m4 >=sys-apps/checkpolicy-2.0.21" @@ -162,25 +158,13 @@ selinux-policy-2_src_prepare() { # Patch the sources with the base patchbundle if [[ -n ${BASEPOL} ]] && [[ "${BASEPOL}" != "" ]]; then cd "${S}" - if [[ ${EAPI:-0} == 5 ]]; then - EPATCH_MULTI_MSG="Applying SELinux policy updates ... " \ - EPATCH_SUFFIX="patch" \ - EPATCH_SOURCE="${WORKDIR}" \ - EPATCH_FORCE="yes" \ - epatch - else - einfo "Applying SELinux policy updates ... " - eapply -p0 "${WORKDIR}/0001-full-patch-against-stable-release.patch" - fi + einfo "Applying SELinux policy updates ... " + eapply -p0 "${WORKDIR}/0001-full-patch-against-stable-release.patch" fi - # Call in epatch_user. We do this early on as we start moving + # Call in eapply_user. We do this early on as we start moving # files left and right hereafter. - if [[ ${EAPI:-0} == 5 ]]; then - epatch_user - else - eapply_user - fi + eapply_user # Copy additional files to the 3rd_party/ location if [[ "$(declare -p POLICY_FILES 2>/dev/null 2>&1)" == "declare -a"* ]] || @@ -195,17 +179,10 @@ selinux-policy-2_src_prepare() { # Apply the additional patches refered to by the module ebuild. # But first some magic to differentiate between bash arrays and strings - if [[ "$(declare -p POLICY_PATCH 2>/dev/null 2>&1)" == "declare -a"* ]] || - [[ -n ${POLICY_PATCH} ]]; then - cd "${S}/refpolicy/policy/modules" - for POLPATCH in ${POLICY_PATCH[@]}; - do - if [[ ${EAPI:-0} == 5 ]]; then - epatch "${POLPATCH}" - else - eapply "${POLPATCH}" - fi - done + if [[ "$(declare -p POLICY_PATCH 2>/dev/null 2>&1)" == "declare -a"* ]]; then + [[ -n ${POLICY_PATCH[*]} ]] && eapply -d "${S}/refpolicy/policy/modules" "${POLICY_PATCH[@]}" + else + [[ -n ${POLICY_PATCH} ]] && eapply -d "${S}/refpolicy/policy/modules" ${POLICY_PATCH} fi # Collect only those files needed for this particular module -- 2.26.2
Re: [gentoo-dev] [PATCH 1/2] selinux-policy-2.eclass: add EAPI 7
On Tue, Nov 3, 2020 at 2:46 AM Ulrich Mueller wrote: > > On Mon, 02 Nov 2020, David Michael wrote: > > > +if [[ ${EAPI:-0} == [56] ]]; then > > Substituting 0 is not necessary here. I wrote it that way to match all other EAPI conditions in the file. I'll remove it in the second patch where the other instances are dropped as well so the commits are self-consistent atomic changes. Thanks. David
[gentoo-dev] Packages up for grabs: dev-libs/intel-neo and dependencies
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 dev-libs/vc-intrinsics [1] dev-util/intel-graphics-compiler dev-util/spirv-llvm-translator media-libs/gmmlib [2] [1] currently unused because intel-graphics-compiler upstream hasn't it made it possible to build against a non-bundled version yet [2] still has got one maintainer (media-video) but with newer versions of NEO frequently depending on new gmmlib features, it will IMHO make sense for the NEO maintainer to co-maintain this library as well No open bugs. Intel upstream (i.e. all but SPIRV-LLVM-Translator) is generally friendly but their response time varies a lot, plus while they do officially support building against system-wide dependencies their own testing focuses primarily on bundling everything together so the distro approach doesn't always work (case in point: VectorCompiler support in recent versions of intel-graphics-compiler, which I have so far only been able to build without errors while using locally available LLVM sources). SPIRV-LLVM-Translator mostly seems to pretend they are not there so chances are you will have to package release snapshots (separately for different LLVM major versions) in order for recent versions of NEO to work; this is why the current stable version in Gentoo is so behind upstream releases. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 2020-11-03 Tue 01:28, Joonas Niilola wrote: > Initially Arfrever suggested the same, I wasn't a fan of it because I > believe it's much simpler to make this into a pkgcheck/repoman check like > this. > > However with pkgcheck maybe a similar logic can be used as is used with > StableRequestCheck. So no objections there I guess. That's simple to achieve with pkgcheck's git support. LiveOnlyCheck now flags packages with only live ebuilds that were all added at least a year ago [1]. [1]: https://github.com/pkgcore/pkgcheck/commit/df4e40c2c2
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/3/20 10:10 AM, Michał Górny wrote: I'm with you on this though I think it should be relaxed to disallow only long term presence of pure live packages. It's fine to add a live ebuild first for a month or two if you're still working on something (just like it's fine to add a masked package). However, it's not fine to leave things like this for years. That said, maybe the policy should cover 'long-term masked packages' in general. See below. Initially Arfrever suggested the same, I wasn't a fan of it because I believe it's much simpler to make this into a pkgcheck/repoman check like this. However with pkgcheck maybe a similar logic can be used as is used with StableRequestCheck. So no objections there I guess. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 2/2] selinux-policy-2.eclass: drop EAPI 5
> On Tue, 03 Nov 2020, Ulrich Mueller wrote: > Presumably it would also be cleaner to test if POLICY_PATCH is an array, > and use '"${POLICY_PATCH[@]}"' if it is but '${POLICY_PATCH}' if it is > not. In fact you could use the same code as in default src_prepare: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-90001r2 Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, 2020-11-03 at 07:13 +0200, Joonas Niilola wrote: > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. I'm with you on this though I think it should be relaxed to disallow only long term presence of pure live packages. It's fine to add a live ebuild first for a month or two if you're still working on something (just like it's fine to add a masked package). However, it's not fine to leave things like this for years. That said, maybe the policy should cover 'long-term masked packages' in general. See below. > Rationale being the same as why > - packages can't have KEYWORDS: They are unpredictable and > potentially insecure. Unpredictability could mean upstream repo being > broken at any given time placing users in an awkward situation, where > they are able to build some packages while not the others. Upstream > repo can also be force-pushed over. I feel like packages offered in > ::gentoo shouldn't have these issues, and the need to have at least one > safe release available to users that's guaranteed to build. I agree with this but I'd like to emphasize one point: these packages are not installable for users out of the box. They are not tested as part of tinderboxing. They simply can't be installed in some environments (e.g. network-restricted) though obviously they're not production-ready by design. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/2] selinux-policy-2.eclass: drop EAPI 5
> On Mon, 02 Nov 2020, David Michael wrote: > for POLPATCH in ${POLICY_PATCH[@]}; > do > - if [[ ${EAPI:-0} == 5 ]]; then > - epatch "${POLPATCH}" > - else > - eapply "${POLPATCH}" > - fi > + eapply "${POLPATCH}" > done eapply can accept multiple parameters, so I think that a simple 'eapply ${POLICY_PATCH[@]}' would do the job. Presumably it would also be cleaner to test if POLICY_PATCH is an array, and use '"${POLICY_PATCH[@]}"' if it is but '${POLICY_PATCH}' if it is not. Ulrich signature.asc Description: PGP signature