Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-03 Thread Sam James


> 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

2020-11-03 Thread Lars Wendler
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

2020-11-03 Thread Conrad Kostecki

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

2020-11-03 Thread David Seifert
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

2020-11-03 Thread Michał Górny
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

2020-11-03 Thread James Le Cuirot
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

2020-11-03 Thread Michał Górny
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

2020-11-03 Thread Michał Górny
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

2020-11-03 Thread Michael Orlitzky

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

2020-11-03 Thread Pacho Ramos
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

2020-11-03 Thread David Seifert
# @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

2020-11-03 Thread Marek Szuba
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

2020-11-03 Thread Marek Szuba
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!

2020-11-03 Thread Marek Szuba

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

2020-11-03 Thread David Michael
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

2020-11-03 Thread David Michael
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

2020-11-03 Thread Marek Szuba
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

2020-11-03 Thread Tim Harder
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

2020-11-03 Thread Joonas Niilola



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

2020-11-03 Thread Ulrich Mueller
> 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

2020-11-03 Thread Michał Górny
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

2020-11-03 Thread Ulrich Mueller
> 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