Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>
>
> > # Don't install libtool archives (even for modules)
> > - prune_libtool_files --all
> > + find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?
I suppose you should have spoken up when people started adopting that
'find' line all over the place. Though I honestly doubt we're going to
see many packages installing '*.la' non-files.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On Tue, 2019-02-19 at 21:23 -0600, Matthew Thode wrote: > As the title says, I think this should be done. > > First sync is impossible to verify without keys (webrsync) > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > in the base install. > This is the wrong place to add it, and the wrong package. If Portage (still) needs it for whatever, then it should be a dependency of Portage. However, app-crypt/openpgp-keys-gentoo-release should be entirely sufficient, and it works without all the voodoo dependencies and 'run programs as root' logic of gkeys. If there's anything in Portage left not using it, it should be ported. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Tue, Feb 19, 2019 at 10:21 PM Ulrich Mueller wrote:
>
> > On Wed, 20 Feb 2019, Matt Turner wrote:
>
> > # Don't install libtool archives (even for modules)
> > - prune_libtool_files --all
> > + find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?
Is that ever a problem? The 'find ...' that I replaced
prune_libtool_files is a verbatim copy of what ltprune.eclass says to
use instead:
# Discouraged. Whenever possible, please use much simpler:
# @CODE
# find "${D}" -name '*.la' -delete || die
# @CODE
grepping the repo, I think a strong case can be made in favor of
ltprune.eclass given the wide variety of ways this is open coded...
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller wrote: > > > On Wed, 20 Feb 2019, Matt Turner wrote: > > > Nearly all the work is just removing uses of autotools-multilib and > > autotools-utils. The new code should work in EAPI 4 and 5. Don't add > > support for EAPI 6; that ship has already sailed. > > AFAICS, adding EAPI 6 support wouldn't require any additional code? I think that is true. (I have no strong preference on whether to add EAPI 6 support. I just figured that anything that gets an EAPI bump now should go to the latest available)
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
> On Wed, 20 Feb 2019, Matt Turner wrote: > Nearly all the work is just removing uses of autotools-multilib and > autotools-utils. The new code should work in EAPI 4 and 5. Don't add > support for EAPI 6; that ship has already sailed. AFAICS, adding EAPI 6 support wouldn't require any additional code? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
> On Wed, 20 Feb 2019, Matt Turner wrote:
> # Don't install libtool archives (even for modules)
> - prune_libtool_files --all
> + find "${D}" -name '*.la' -delete || die
Maybe restrict removal to regular files, i.e. add "-type f"?
signature.asc
Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On Tue, 19 Feb 2019 23:03:51 -0600 Matthew Thode wrote: > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > >> > > >> What problem would this solve? (Is adding gentoo-keys to @system > > >> the least bad way to solve it?) > > >> > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > portage tarballs. This is useful for the initial sync (as called > > > out in our manual). Otherwise using emerge-webrsync could be > > > mitm'd or otherwise messed with. > > > > Ok, then I agree with the goal if not the solution. This is a > > portage-specific thing, namely > > > > FEATURES=webrsync-gpg > > > > that should be enabled by default on a stage3. (Making new users go > > out of their way to add basic security is daft.) Portage already has > > USE=rsync-verify, and I think we could either > > > > a) expand the meaning of that flag to include enabling > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > That flag would be enabled by default, so gentoo-keys would be > > pulled in as part of @system without actually being *in* the > > @system. Something along those lines would achieve the same goal in > > a cleaner way. > > > > > > This worksforme (optional, default enabled dep of portage with a > default feature flag change). > > > > As far how we treat deps of @system packages, since this does not > > > have any deps that should help check that box for anyone > > > worried. > > > > I meant the other way around. Once gentoo-keys is in @system, > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > There's no real policy or consensus on the matter, and it makes it > > a real PITA if we ever want to remove things from @system, because > > lots of packages will break in unpredictable ways. > > > > Ah, ya, that makes sense. > One of the things that releng has bantered about the last few years is making a stage4 with these extra non @system pkgs. The stage4 would allow all the extra pkgs needed for new installs without adding to @system. The system set could possibly be trimmed a little more then too. Then knowledgeable users could work with minimal stage3's when it suits their purpose while new users doing installs get the advantage of the additional pre-installed pkgs.
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-20 00:00:04, Michael Orlitzky wrote: > On 2/19/19 11:21 PM, Matthew Thode wrote: > >> > >> What problem would this solve? (Is adding gentoo-keys to @system the > >> least bad way to solve it?) > >> > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > portage tarballs. This is useful for the initial sync (as called out in > > our manual). Otherwise using emerge-webrsync could be mitm'd or > > otherwise messed with. > > Ok, then I agree with the goal if not the solution. This is a > portage-specific thing, namely > > FEATURES=webrsync-gpg > > that should be enabled by default on a stage3. (Making new users go out > of their way to add basic security is daft.) Portage already has > USE=rsync-verify, and I think we could either > > a) expand the meaning of that flag to include enabling webrsync-gpg > by default, and to pull in gentoo-keys; or > > b) add another (default-on) flag like USE=webrsync-verify to do it > > That flag would be enabled by default, so gentoo-keys would be pulled in > as part of @system without actually being *in* the @system. Something > along those lines would achieve the same goal in a cleaner way. > > This worksforme (optional, default enabled dep of portage with a default feature flag change). > > As far how we treat deps of @system packages, since this does not have > > any deps that should help check that box for anyone worried. > > I meant the other way around. Once gentoo-keys is in @system, packages > will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real > policy or consensus on the matter, and it makes it a real PITA if we > ever want to remove things from @system, because lots of packages will > break in unpredictable ways. > Ah, ya, that makes sense. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 2/19/19 11:21 PM, Matthew Thode wrote: >> >> What problem would this solve? (Is adding gentoo-keys to @system the >> least bad way to solve it?) >> > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > portage tarballs. This is useful for the initial sync (as called out in > our manual). Otherwise using emerge-webrsync could be mitm'd or > otherwise messed with. Ok, then I agree with the goal if not the solution. This is a portage-specific thing, namely FEATURES=webrsync-gpg that should be enabled by default on a stage3. (Making new users go out of their way to add basic security is daft.) Portage already has USE=rsync-verify, and I think we could either a) expand the meaning of that flag to include enabling webrsync-gpg by default, and to pull in gentoo-keys; or b) add another (default-on) flag like USE=webrsync-verify to do it That flag would be enabled by default, so gentoo-keys would be pulled in as part of @system without actually being *in* the @system. Something along those lines would achieve the same goal in a cleaner way. > As far how we treat deps of @system packages, since this does not have > any deps that should help check that box for anyone worried. I meant the other way around. Once gentoo-keys is in @system, packages will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real policy or consensus on the matter, and it makes it a real PITA if we ever want to remove things from @system, because lots of packages will break in unpredictable ways.
[gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
Nearly all the work is just removing uses of autotools-multilib and
autotools-utils. The new code should work in EAPI 4 and 5. Don't add
support for EAPI 6; that ship has already sailed.
---
There are a number of trivial x11 bumps coming up, so I figured I'd try
to finally add EAPI=7 support to xorg-2.eclass. This is lightly tested,
and I don't feel like an expert at this, so any review and feedback is
appreciated.
I find the if-multilib ... fi blocks a little odd. Is there a better way
to do that?
eclass/xorg-2.eclass | 80 ++--
1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 74660e7f213..eb2aa1594b4 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: xorg-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author: Tomáš Chvátal
# Author: Donnie Berkholz
-# @SUPPORTED_EAPIS: 4 5
+# @SUPPORTED_EAPIS: 4 5 7
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -44,16 +44,16 @@ fi
: ${XORG_MULTILIB:="no"}
# we need to inherit autotools first to get the deps
-inherit autotools autotools-utils eutils libtool multilib toolchain-funcs \
+inherit autotools eutils libtool multilib toolchain-funcs \
flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
if [[ ${XORG_MULTILIB} == yes ]]; then
- inherit autotools-multilib
+ inherit multilib-minimal
fi
-EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile
src_install pkg_postinst pkg_postrm"
case "${EAPI:-0}" in
- 4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
+ 4|5|7) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
@@ -129,7 +129,16 @@ for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
done
DEPEND+=" ${EAUTORECONF_DEPENDS}"
-[[ ${XORG_EAUTORECONF} != no ]] && DEPEND+=" ${EAUTORECONF_DEPEND}"
+if [[ ${XORG_EAUTORECONF} != no ]] ; then
+ case "${EAPI:-0}" in
+ 4|5)
+ DEPEND+=" ${EAUTORECONF_DEPEND}"
+ ;;
+ 7)
+ BDEPEND+=" ${EAUTORECONF_DEPEND}"
+ ;;
+ esac
+fi
unset EAUTORECONF_DEPENDS
unset EAUTORECONF_DEPEND
@@ -311,20 +320,6 @@ xorg-2_src_unpack() {
[[ -n ${FONT_OPTIONS} ]] && einfo "Detected font directory: ${FONT_DIR}"
}
-# @FUNCTION: xorg-2_patch_source
-# @DESCRIPTION:
-# Apply all patches
-xorg-2_patch_source() {
- debug-print-function ${FUNCNAME} "$@"
-
- # Use standardized names and locations with bulk patching
- # Patch directory is ${WORKDIR}/patch
- # See epatch() in eutils.eclass for more documentation
- EPATCH_SUFFIX=${EPATCH_SUFFIX:=patch}
-
- [[ -d "${EPATCH_SOURCE}" ]] && epatch
-}
-
# @FUNCTION: xorg-2_reconf_source
# @DESCRIPTION:
# Run eautoreconf if necessary, and run elibtoolize.
@@ -335,14 +330,17 @@ xorg-2_reconf_source() {
*-aix* | *-winnt*)
# some hosts need full eautoreconf
[[ -e "./configure.ac" || -e "./configure.in" ]] \
- && AUTOTOOLS_AUTORECONF=1
+ && XORG_EAUTORECONF=yes
;;
*)
# elibtoolize required for BSD
[[ ${XORG_EAUTORECONF} != no && ( -e "./configure.ac"
|| -e "./configure.in" ) ]] \
- && AUTOTOOLS_AUTORECONF=1
+ && XORG_EAUTORECONF=yes
;;
esac
+
+ [[ ${XORG_EAUTORECONF} != no ]] && eautoreconf
+ elibtoolize --patch-only
}
# @FUNCTION: xorg-2_src_prepare
@@ -351,9 +349,10 @@ xorg-2_reconf_source() {
xorg-2_src_prepare() {
debug-print-function ${FUNCNAME} "$@"
- xorg-2_patch_source
+ default
xorg-2_reconf_source
- autotools-utils_src_prepare "$@"
+
+ [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
}
# @FUNCTION: xorg-2_font_configure
@@ -447,17 +446,28 @@ xorg-2_src_configure() {
local selective_werror="--disable-selective-werror"
fi
- local myeconfargs=(
+ local econfargs=(
${dep_track}
${selective_werror}
${FONT_OPTIONS}
"${xorgconfadd[@]}"
)
+ # Handle static-libs found in IUSE, disable them by default
+ if in_iuse static-libs; then
+ econfargs+=(
+ --enable-shared
+ $(use_enable static-libs static)
[gentoo-dev] [PATCH 1/3] xorg-2.eclass: Drop support for EAPI 3
No ebuilds inheriting xorg-2 are EAPI=3.
---
eclass/xorg-2.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 4ed65e676a0..7133aa365f1 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author: Tomáš Chvátal
# Author: Donnie Berkholz
-# @SUPPORTED_EAPIS: 3 4 5
+# @SUPPORTED_EAPIS: 4 5
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -53,7 +53,7 @@ fi
EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
case "${EAPI:-0}" in
- 3|4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
+ 4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
@@ -271,7 +271,7 @@ fi
if [[ ${XORG_MODULE_REBUILD} == yes ]]; then
case ${EAPI} in
- 3|4)
+ 4)
;;
*)
RDEPEND+=" x11-base/xorg-server:="
@@ -530,7 +530,7 @@ xorg-2_pkg_postrm() {
if [[ -n ${FONT} ]]; then
# if we're doing an upgrade, postinst will do
- if [[ ${EAPI} -lt 4 || -z ${REPLACED_BY_VERSION} ]]; then
+ if [[ -z ${REPLACED_BY_VERSION} ]]; then
create_fonts_scale
create_fonts_dir
font_pkg_postrm "$@"
--
2.19.2
[gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
---
eclass/xorg-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 7133aa365f1..74660e7f213 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -500,7 +500,7 @@ xorg-2_src_install() {
fi
# Don't install libtool archives (even for modules)
- prune_libtool_files --all
+ find "${D}" -name '*.la' -delete || die
[[ -n ${FONT} ]] && remove_font_metadata
}
--
2.19.2
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 19-02-19 23:04:26, Michael Orlitzky wrote: > On 2/19/19 10:23 PM, Matthew Thode wrote: > > As the title says, I think this should be done. > > > > First sync is impossible to verify without keys (webrsync) > > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > > in the base install. > > > > Let the bikeshedding begin. > > > > I don't have app-crypt/gentoo-keys installed. I seem to be doing okay > without it. > > In any case, on principle, we shouldn't add anything else to @system. No > one agrees on how we should treat @system packages as far as > dependencies go, and the whole idea is a stinky pile of dirty laundry > that we should work to make explicit instead. > > What problem would this solve? (Is adding gentoo-keys to @system the > least bad way to solve it?) > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify portage tarballs. This is useful for the initial sync (as called out in our manual). Otherwise using emerge-webrsync could be mitm'd or otherwise messed with. As far how we treat deps of @system packages, since this does not have any deps that should help check that box for anyone worried. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 2/19/19 10:23 PM, Matthew Thode wrote: > As the title says, I think this should be done. > > First sync is impossible to verify without keys (webrsync) > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat > in the base install. > > Let the bikeshedding begin. > I don't have app-crypt/gentoo-keys installed. I seem to be doing okay without it. In any case, on principle, we shouldn't add anything else to @system. No one agrees on how we should treat @system packages as far as dependencies go, and the whole idea is a stinky pile of dirty laundry that we should work to make explicit instead. What problem would this solve? (Is adding gentoo-keys to @system the least bad way to solve it?)
[gentoo-dev] adding app-crypt/gentoo-keys to @system
As the title says, I think this should be done. First sync is impossible to verify without keys (webrsync) app-crypt/gentoo-keys has no dependencies, which help avoid some bloat in the base install. Let the bikeshedding begin. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature
Re: [gentoo-dev] Deprecation and removal of 13.0 profiles is imminent
On Sun, 16 Dec 2018 19:56:38 + Sergei Trofimovich wrote: > On Wed, 12 Dec 2018 00:25:04 + > Sergei Trofimovich wrote: > > > Tl;DR: 13.0 profiles will be removed some time soon unless there are > > enough reports broken on 13.0->17.0 switch. > > > > 13.0 profiles been a while in Gentoo tree and are already deprecated > > on some arches but not everywhere. > > > > If you have problems using 17.0 profiles as a default please file a bug > > and pile it against against the tracker bug (fresh one): > > https://bugs.gentoo.org/672960 > > I filed a bunch of bugs to deprecate existing profile that rely on > 'releases/13.0' profile snippet. > > To deprecate a profile just drop a 'deprecated' file to profile dir > that targets to target for users to switch to. Example: > https://bugs.gentoo.org/672960#c2 > Note: package.desc still remains > > At removal time we will delete both deprecated profiles and package.desc > entries. A few months passed and we almost finished with a long tail. To-be-deprecated profiles yet are: https://bugs.gentoo.org/673278 prefix/linux-standalone/ppc64 +prefix@, what is our plan here? Can we drop at least empty 'deprecated' file to notify users? https://bugs.gentoo.org/673276 hardened/linux/arm/armv6j hardened/linux/arm/armv7a hardened/linux/mips/mipsel/multilib/n32 hardened/linux/mips/mipsel/multilib/n64 hardened/linux/mips/mipsel/n32 hardened/linux/mips/mipsel/n64 hardened/linux/mips/multilib/n32 hardened/linux/mips/multilib/n64 hardened/linux/mips/n32 hardened/linux/mips/n64 hardened/linux/powerpc/ppc32 hardened/linux/powerpc/ppc64/32bit-userland hardened/linux/powerpc/ppc64/64bit-userland +hardened@ (and +arm@, +mips@, +ppc@, +ppc64) , is it fine to redirect these to vanilla 17.0 profiles? -- Sergei
