Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote: > The TL;DR is that a crack team of infra-folks[0] have been putting together > demos of CI services and things like gitlab / gitea / gerrit and so on. > > Some of these come in combined (e.g. gitlab offers repo hosting, code > review / pull reqs, CI services, and deploy services.) Some of these are > piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers > repo-hosting but CI is separate (e.g. drone.) > > On the infra-side, I think we are pretty happy with repo-hosting (gitolite) > and repo-serving (gitweb). We are missing a CI piece and a pull-request > piece. Most of the users using PRs use either a gitlab or github mirror. > > I think the value of CI is pretty obvious to me (and I see tons of use > cases in Infra.) We could easily build CI into our current repository > solution (e.g. gitolite.) However gitolite doesn't really support PRs in a > uniform way and so CI is mostly for submitted code; similar to the existing > ::gentoo repo CI offered by mgorny. > > If we build a code review solution (like gitea / gerrit) would people use > it? Would you use it if you couldn't merge (because the code review > solution can't gpg sign your commits or merges) so a tool like the existing > pram tool would be needed to merge? > Does GitLab count? Gerrit is just PITA. I think we had some concerns about Gitea, so I'd like to test it before deciding. GitLab OTOH works just fine for a lot of projects, and seems the next best thing after GitHub. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] New eclass: openvdb.eclass
Hello, I am a proxied maintainer of blender and openvdb and wish to propose a
new eclass and USE_EXPAND variable to ensure the same version of the openvdb
abi is used when building the blender, openvdb and openimageio packages.
The tree currently contains openvdb 4 and 5, and I plan to add 6 and 7 soon to
support my new blender PR. Each major release of openvdb has a new ABI, and can
also support legacy versions. However only one version can be built at a time,
which is passed to cmake through OPENVDB_ABI_VERSION_NUMBER, and produces a
library with functions named xxx_7abi5 when building openvdb 7 with support for
abi 5. Client packages like blender and openimageio which depend on openvdb and
also need to be compiled with the same version number in order to link
correctly.
To enforce this I propose to add a new USE_EXPAND variable called OPENVDB_ABI,
which is set to the version number the user wants to use in the system eg 5,
which expands to openvdb_abi_5. The packages can then append
-DOPENVDB_ABI_VERSION_NUMBER=${OPENVDB_ABI} to ensure they pass the same value
to cmake.
To reduce the boilerplate code required to ensure that only one supported value
is set in OPENVDB_ABI and used by all packages, so I propose to add an eclass
to maintain this in one place. Similar to PYTHON_COMPAT, each ebuilds set
OPENVDB_COMPAT to specify which legacy ABI they can support. The openvdb.eclass
uses it to set global variables OPENVDB_REQUIRED_USE and OPENVDB_SINGLE_USEDEP
and verify in pkg_prepare that only one of the openvdb_abi_X flags is set.
Each ebuild sets REQUIRED_USE="${OPENVDB_REQUIRED_USE}" which evaluates to ^^ (
openvdb_abi_3 openvdb_abi_4 ... ) to ensure only one abi is enabled from those
it supports.
They set RDEPEND="openvdb? ( media-gfx/openvdb[${OPENVDB_SINGLE_USEDEP}] )"
which evaluates to openvdb_abi_3(-)?,openvdb_abi_4(-)?,... to allow portage to
enforce the same abi version is built between all packages.
With a new release of openvdb, I will only need to add it to the
openvdb_abi.desc file, to an eclass internal list _OPENVDB_ALL_ABI, and to
OPENVDB_COMPAT for each ebuild which supports the new version.
Please review my proposed eclass below. I have tested it works when OPENVDB_ABI
is missing, set to invalid values, or set to values that cannot satisfy all
package requirements simultaneously, and that the system recompiles all
packages when the ABI is changed. It also works when set to appropriate values.
I considered other alternatives during development. It is possible to manually
add the expanded REQUIRED_USE and RDEPEND strings to each package, but with
each new version of openvdb and multiple client packages to maintain this
becomes messy and error prone. The user also needs to set the same
openvdb_abi_X flag for each package. While currently there are only three
packages which need to be synchronised, any other package which depends on
openvdb in future will benefit from this infrastructure.
Also without the USE_EXPAND variable the ebuilds do not have access to the
version number to pass to the build system, and need to generate it by testing
each USE flag. So I think this is the cleanest solution.
I also looked into slotting openvdb as then packages could specify the
slot/subslot required eg openvdb:7/5 but don't think this is possible. This
would be a major undertaking as it has a static as well as dynamic core
library, another library for python, and the cmake modules that find openvdb
use the output of a binary at /usr/bin/vdb_print to determine which version to
link against. It would also not centralise the boilerplate code.
For further information and my discussion during development see
https://github.com/redchillipadi/ebuild-overlay/issues/4
Please let me know if there is a better solution or improvements are required.
Kind Regards,
Adrian Grigo
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: openvdb.eclass
# @MAINTAINER:
# Adrian Grigo
# @ AUTHOR:
# Author: Adrian Grigo
# Based on work of: Michał Górny and Krzysztof Pawlik
# @SUPPORTED_EAPIS: 5 6 7
# @BLURB: An eclass for OpenVDB to control which ABI version is compiled
# @DESCRIPTION:
# The OpenVDB package is a library for sorting and manipulating sparse
# data structures with dynamic topology as required for use in volume
# rendering for computer graphics.
#
# Each major version of OpenVDB provides an updated ABI, as well as
# the ability to compile using a legacy version of the ABI.
# Openvdb 7 can be compiled to support version 5, 6 or 7 of the ABI.
#
# However the user needs to choose at compile time which version to
# build by passing OPENVDB_ABI_VERSION_NUMBER="5" to cmake.
# It is not possible to support multiple versions concurrently
# so OpenVDB and all packages depending upon it must be built for the
# same ABI version. This currently means blender and openvdb, and
# will also include >=openimageio-2
[gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
The TL;DR is that a crack team of infra-folks[0] have been putting together demos of CI services and things like gitlab / gitea / gerrit and so on. Some of these come in combined (e.g. gitlab offers repo hosting, code review / pull reqs, CI services, and deploy services.) Some of these are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers repo-hosting but CI is separate (e.g. drone.) On the infra-side, I think we are pretty happy with repo-hosting (gitolite) and repo-serving (gitweb). We are missing a CI piece and a pull-request piece. Most of the users using PRs use either a gitlab or github mirror. I think the value of CI is pretty obvious to me (and I see tons of use cases in Infra.) We could easily build CI into our current repository solution (e.g. gitolite.) However gitolite doesn't really support PRs in a uniform way and so CI is mostly for submitted code; similar to the existing ::gentoo repo CI offered by mgorny. If we build a code review solution (like gitea / gerrit) would people use it? Would you use it if you couldn't merge (because the code review solution can't gpg sign your commits or merges) so a tool like the existing pram tool would be needed to merge? -A [0] Mostly arzano, if I'm honest. I am just the point-y haired manager in this effort.
[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.
I noticed that gcc-config recently gained --enable-native-links /
--disable-native-links knobs that are . Will this patch with a renamed
option name
e.g. --disable-default-cc-vars and support for a USE flag work?
Thanks,
Manoj
On Wed, Mar 11, 2020 at 9:07 AM Manoj Gupta wrote:
>
>
> On Wed, Mar 11, 2020 at 12:49 AM Sergei Trofimovich
> wrote:
>
>> On Tue, 10 Mar 2020 20:54:12 -0700
>> Manoj Gupta wrote:
>>
>> > On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich
>> wrote:
>> >
>> > > On Mon, 2 Mar 2020 19:03:48 -0800
>> > > Manoj Gupta wrote:
>> > >
>> > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <
>> sly...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta
>>
>> > > wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <
>> manojgu...@google.com>
>> > >
>> > > > > wrote:
>> > > > > >>
>> > > > > >> gcc-config installs cc/f77 by default. This may be undesired on
>> > > > > >> systems that want to set their own versions of cc/f77.
>> > > > > >>
>> > > > > >> Add option "-n"/"--no-default-vars" to not install the cc/f77
>> > > > > >> wrappers.
>> > > > > >>
>> > > > > >> Signed-off-by: Manoj Gupta
>> > > > > >> ---
>> > > > > >> gcc-config | 6 +-
>> > > > > >> 1 file changed, 5 insertions(+), 1 deletion(-)
>> > > > > >>
>> > > > > >> diff --git a/gcc-config b/gcc-config
>> > > > > >> index f03a46a..6f306db 100755
>> > > > > >> --- a/gcc-config
>> > > > > >> +++ b/gcc-config
>> > > > > >> @@ -262,7 +262,7 @@ update_wrappers() {
>> > > > > >> # For all toolchains, we want to create the fully
>> qualified
>> > > > > >> # `tuple-foo`. Only native ones do we want the
>> simple
>> > > `foo`.
>> > > > > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} )
>> > > > > >> - if ! is_cross_compiler ; then
>> > > > > >> + if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" ==
>> "yes"
>> > > ]];
>> > > > > then
>> > > > > >> all_wrappers+=( "${new_wrappers[@]}" )
>> > > > > >> # There are a few fun extra progs which we
>> have to
>> > > > > handle #412319
>> > > > > >> all_wrappers+=( cc:gcc f77:g77 )
>> > > > > >> @@ -951,6 +951,7 @@ FORCE="no"
>> > > > > >> CC_COMP=
>> > > > > >> ENV_D="${EROOT}etc/env.d"
>> > > > > >> GCC_ENV_D="${ENV_D}/gcc"
>> > > > > >> +DEFAULT_PROGS="yes"
>> > > > > >>
>> > > > > >> for x in "$@" ; do
>> > > > > >> case "${x}" in
>> > > > > >> @@ -972,6 +973,9 @@ for x in "$@" ; do
>> > > > > >> -l|--list-profiles)
>> > > > > >> set_doit list_profiles
>> > > > > >> ;;
>> > > > > >> + -n|--no-default-vars)
>> > > > > >> + DEFAULT_PROGS="no"
>> > > > > >> + ;;
>> > > > > >> -S|--split-profile)
>> > > > > >> if [[ ( $1 != "-S" && $1 !=
>> > > "--split-profile" )
>> > > > > || $# -eq 1 ]] ; then
>> > > > > >> usage 1
>> > > > > >> --
>> > > > > >>
>> > > > > >
>> > > > > > Not sure of the correct mailing list for patches to gcc-config
>> so
>> > > also
>> > > > > adding toolchain@gentoo .
>> > > > > >
>> > > > >
>> > > > > toolch...@gentoo.org should generally be fine.
>> > > > >
>> > > > > Today cc->gcc and gcc->${CHOST}-gcc symlinks are effectively
>> owned by
>> > > > > a single sys-devel/gcc-config package.
>> > > > > gcc-config is calld to update symlinks every time sys-devel/gcc is
>> > > > > installed/updated. That way we never get cc/gcc
>> > > > > out of sync.
>> > > > >
>> > > > > Your change makes /usr/bin/cc an orphan symlink. I think we need
>> to
>> > > > > still keep a 'cc'/'f77' ownership somewhere
>> > > > > (say, a separate package).
>> > > > >
>> > > > > I suggest making a decision to handle or not handle 'cc'/'f77' and
>> > > > > gcc-config build-time, not gcc-config call-time.
>> > > > > That way sys-devel/gcc updates will behave the same as manual
>> > > > > 'gcc-config-' calls.
>> > > > >
>> > > > > Mechanically that could be a Makefile variable that switches the
>> > > > > behaviour on/off at
>> > > > > https://gitweb.gentoo.org/proj/gcc-config.git/tree/Makefile
>> > > > > and exposed as an USE flag on sys-devel/gcc-config ebuild.
>> > > > >
>> > > > > Later we can create a separate ebuild to manage /usr/bin/cc. For
>> gcc
>> > > > > it's not hard, as gcc-config always provides /usr/bin/gcc and
>> > > > > /usr/bin/${CHOST}-gcc.
>> > > > > These can be static symlinks that don't require maintenance
>> updates.
>> > > > >
>> > > > > Thanks for the suggestion. I will look into adding a Makefile
>> > > variable
>> > > > exposed via an USE flag.
>> > >
>> > > You might also need to look in the detail at 'c++', 'cpp' and
>> ${CHOST}-*
>> > > equivalents
>> > > as those also get linked by gcc-config:
>> > >
>> > > $ LANG=C ls -l /usr/bin/ | fgrep 10.0.1 | fgrep -v -- '-10.0.1 ->'
>>
Re: [gentoo-dev] Packages up for grabs
On Tue, 26 May 2020 23:12:06 +0100 Andrey Utkin wrote: > I have transitioned to "away" state as I have to reclaim my time for > other uses. Here I am trying to reduce the scope of my Gentoo > responsibilities to make potential return to activity less dreadful > and overwhelming. > > Call for successors > === > > The following are the packages I do not currently use myself so have > the least motivation about. Dropping me from maintainers list is > encouraged. > > WIFI access point service: > > * net-wireless/hostapd > (Co-maintained by zerochaos, still additional attention is > encouraged.) > > Python API for AWS: > > * dev-python/s3transfer > * dev-python/boto3 > * dev-python/botocore I can take boto3, botocore since they are needed for buildbot
[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.
On Tue, 26 May 2020 15:13:47 -0700
Manoj Gupta wrote:
> I noticed that gcc-config recently gained --enable-native-links /
> --disable-native-links knobs that are . Will this patch with a renamed
> option name
> e.g. --disable-default-cc-vars and support for a USE flag work?
That can work. Let's try and see how the end result looks like.
> Thanks,
> Manoj
>
> On Wed, Mar 11, 2020 at 9:07 AM Manoj Gupta wrote:
>
> >
> >
> > On Wed, Mar 11, 2020 at 12:49 AM Sergei Trofimovich
> > wrote:
> >
> >> On Tue, 10 Mar 2020 20:54:12 -0700
> >> Manoj Gupta wrote:
> >>
> >> > On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich
> >> wrote:
> >> >
> >> > > On Mon, 2 Mar 2020 19:03:48 -0800
> >> > > Manoj Gupta wrote:
> >> > >
> >> > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <
> >> sly...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta
> >>
> >> > > wrote:
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <
> >> manojgu...@google.com>
> >> > >
> >> > > > > wrote:
> >> > > > > >>
> >> > > > > >> gcc-config installs cc/f77 by default. This may be undesired on
> >> > > > > >> systems that want to set their own versions of cc/f77.
> >> > > > > >>
> >> > > > > >> Add option "-n"/"--no-default-vars" to not install the cc/f77
> >> > > > > >> wrappers.
> >> > > > > >>
> >> > > > > >> Signed-off-by: Manoj Gupta
> >> > > > > >> ---
> >> > > > > >> gcc-config | 6 +-
> >> > > > > >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >> > > > > >>
> >> > > > > >> diff --git a/gcc-config b/gcc-config
> >> > > > > >> index f03a46a..6f306db 100755
> >> > > > > >> --- a/gcc-config
> >> > > > > >> +++ b/gcc-config
> >> > > > > >> @@ -262,7 +262,7 @@ update_wrappers() {
> >> > > > > >> # For all toolchains, we want to create the fully
> >> qualified
> >> > > > > >> # `tuple-foo`. Only native ones do we want the
> >> simple
> >> > > `foo`.
> >> > > > > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} )
> >> > > > > >> - if ! is_cross_compiler ; then
> >> > > > > >> + if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" ==
> >> "yes"
> >> > > ]];
> >> > > > > then
> >> > > > > >> all_wrappers+=( "${new_wrappers[@]}" )
> >> > > > > >> # There are a few fun extra progs which we
> >> have to
> >> > > > > handle #412319
> >> > > > > >> all_wrappers+=( cc:gcc f77:g77 )
> >> > > > > >> @@ -951,6 +951,7 @@ FORCE="no"
> >> > > > > >> CC_COMP=
> >> > > > > >> ENV_D="${EROOT}etc/env.d"
> >> > > > > >> GCC_ENV_D="${ENV_D}/gcc"
> >> > > > > >> +DEFAULT_PROGS="yes"
> >> > > > > >>
> >> > > > > >> for x in "$@" ; do
> >> > > > > >> case "${x}" in
> >> > > > > >> @@ -972,6 +973,9 @@ for x in "$@" ; do
> >> > > > > >> -l|--list-profiles)
> >> > > > > >> set_doit list_profiles
> >> > > > > >> ;;
> >> > > > > >> + -n|--no-default-vars)
> >> > > > > >> + DEFAULT_PROGS="no"
> >> > > > > >> + ;;
> >> > > > > >> -S|--split-profile)
> >> > > > > >> if [[ ( $1 != "-S" && $1 !=
> >> > > "--split-profile" )
> >> > > > > || $# -eq 1 ]] ; then
> >> > > > > >> usage 1
> >> > > > > >> --
> >> > > > > >>
> >> > > > > >
> >> > > > > > Not sure of the correct mailing list for patches to gcc-config
> >> so
> >> > > also
> >> > > > > adding toolchain@gentoo .
> >> > > > > >
> >> > > > >
> >> > > > > toolch...@gentoo.org should generally be fine.
> >> > > > >
> >> > > > > Today cc->gcc and gcc->${CHOST}-gcc symlinks are effectively
> >> owned by
> >> > > > > a single sys-devel/gcc-config package.
> >> > > > > gcc-config is calld to update symlinks every time sys-devel/gcc is
> >> > > > > installed/updated. That way we never get cc/gcc
> >> > > > > out of sync.
> >> > > > >
> >> > > > > Your change makes /usr/bin/cc an orphan symlink. I think we need
> >> to
> >> > > > > still keep a 'cc'/'f77' ownership somewhere
> >> > > > > (say, a separate package).
> >> > > > >
> >> > > > > I suggest making a decision to handle or not handle 'cc'/'f77' and
> >> > > > > gcc-config build-time, not gcc-config call-time.
> >> > > > > That way sys-devel/gcc updates will behave the same as manual
> >> > > > > 'gcc-config-' calls.
> >> > > > >
> >> > > > > Mechanically that could be a Makefile variable that switches the
> >> > > > > behaviour on/off at
> >> > > > > https://gitweb.gentoo.org/proj/gcc-config.git/tree/Makefile
> >> > > > > and exposed as an USE flag on sys-devel/gcc-config ebuild.
> >> > > > >
> >> > > > > Later we can create a separate ebuild to manage /usr/bin/cc. For
> >> gcc
> >> > > > > it's not hard, as gcc-config always provides /usr/bin/gcc and
> >> > > > > /usr/bin/${CHOST}-
Re: [gentoo-dev] Packages up for grabs
> On 26 May 2020, at 23:12, Andrey Utkin wrote: > > I have transitioned to "away" state as I have to reclaim my time for other > uses. Here I am trying to reduce the scope of my Gentoo responsibilities to > make potential return to activity less dreadful and overwhelming. Nothing wrong with reprioritising. Better to do that, rather than burn out. > > WIFI access point service: > > * net-wireless/hostapd > (Co-maintained by zerochaos, still additional attention is encouraged.) > > > Raspberry Pi packages: > > * media-libs/raspberrypi-userland-bin > * sys-boot/raspberrypi-firmware > * sys-kernel/raspberrypi-image > * sys-kernel/raspberrypi-sources I am quite happy to help with these, as I’m an active user of most of them. Best, Sam
[gentoo-dev] Packages up for grabs
I have transitioned to "away" state as I have to reclaim my time for other uses. Here I am trying to reduce the scope of my Gentoo responsibilities to make potential return to activity less dreadful and overwhelming. Call for successors === The following are the packages I do not currently use myself so have the least motivation about. Dropping me from maintainers list is encouraged. WIFI access point service: * net-wireless/hostapd (Co-maintained by zerochaos, still additional attention is encouraged.) Python API for AWS: * dev-python/s3transfer * dev-python/boto3 * dev-python/botocore * dev-python/guzzle_sphinx_theme TUI XMPP clients: * net-im/mcabber * net-im/poezio * net-im/profanity * net-libs/loudmouth * dev-libs/libstrophe * dev-python/slixmpp Somewhat obscure build system: * dev-util/tup V4L: * media-libs/libv4l * media-tv/v4l-utils Call for co-maintainers or successors = For these I have some minor use. You can expect me to have some interest revived. Still, taking responsibility for them in my absence is highly appreciated. GUI XMPP client: * net-im/dino * net-libs/libsignal-protocol-c XMPP server software: * net-im/spectrum2 * net-im/swift Raspberry Pi packages: * media-libs/raspberrypi-userland-bin * sys-boot/raspberrypi-firmware * sys-kernel/raspberrypi-image * sys-kernel/raspberrypi-sources CardDAV CLI tool: * app-misc/khard * dev-python/ruamel-std-pathlib * dev-python/ruamel-yaml-clib * dev-python/ruamel-yaml signature.asc Description: PGP signature
[gentoo-dev] [PATCH v2] kernel-2.eclass: avoid lexicographical compare on versions, bug #705246
Originally found in bug #705240 as:
```
if [[ ... || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.28 ]]; then
```
'>' are string comparisons. They are benign so far, but
will start failing on linux-10 :)
Let's be consistent and use version comparison.
Closes: https://bugs.gentoo.org/705246
Signed-off-by: Sergei Trofimovich
---
Change since v1:
- fixed syntax around compound conditionals:
'[[ foo || ver_test bar ]]' -> '[[ foo ]] || ver_test bar'
eclass/kernel-2.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 07af8d8ab2c..930bcf22e29 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1015,7 +1015,7 @@ postinst_sources() {
# K_SECURITY_UNSUPPORTED=deblob
# if we are to forcably symlink, delete it if it already exists first.
- if [[ ${K_SYMLINK} > 0 ]]; then
+ if [[ ${K_SYMLINK} -gt 0 ]]; then
[[ -h ${EROOT}usr/src/linux ]] && { rm "${EROOT}"usr/src/linux
|| die; }
MAKELINK=1
fi
@@ -1078,7 +1078,7 @@ postinst_sources() {
KV_PATCH=$(ver_cut 3 ${OKV})
if [[ "$(tc-arch)" = "sparc" ]]; then
if [[ $(gcc-major-version) -lt 4 && $(gcc-minor-version) -lt 4
]]; then
- if [[ ${KV_MAJOR} -ge 3 ||
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} > 2.6.24 ]] ; then
+ if [[ ${KV_MAJOR} -ge 3 ]] || ver_test
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.24 ; then
echo
elog "NOTE: Since 2.6.25 the kernel Makefile
has changed in a way that"
elog "you now need to do"
@@ -1272,7 +1272,7 @@ unipatch() {
# do not apply fbcondecor patch to sparc/sparc64 as it breaks boot
# bug #272676
if [[ "$(tc-arch)" = "sparc" || "$(tc-arch)" = "sparc64" ]]; then
- if [[ ${KV_MAJOR} -ge 3 || ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}
> 2.6.28 ]]; then
+ if [[ ${KV_MAJOR} -ge 3 ]] || ver_test
${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} -gt 2.6.28 ; then
if [[ ! -z ${K_WANT_GENPATCHES} ]] ; then
UNIPATCH_DROP="${UNIPATCH_DROP}
*_fbcondecor*.patch"
echo
@@ -1521,7 +1521,7 @@ kernel-2_src_unpack() {
# fix a problem on ppc where TOUT writes to /usr/src/linux breaking
sandbox
# only do this for kernel < 2.6.27 since this file does not exist in
later
# kernels
- if [[ -n ${KV_MINOR} && ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH} < 2.6.27
]] ; then
+ if [[ -n ${KV_MINOR} ]] && ver_test ${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}
-lt 2.6.27 ; then
sed -i \
-e 's|TOUT := .tmp_gas_check|TOUT :=
$(T).tmp_gas_check|' \
"${S}"/arch/ppc/Makefile
--
2.26.2
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
tisdag 26 maj 2020 kl. 19:54:51 CEST skrev Alexis Ballier: > On Tue, 26 May 2020 10:45:39 -0400 > > Mike Gilbert wrote: > > > Note that having the 'pic' useflag should be considered something > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > has the will to do it since this is mostly an issue on x86+pax, > > > both being slowly decreasing. > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > the grsecurity licensing issue, I wonder if there is any other good > > reason to keep the "pic" USE flag today. Surely this affects a very > > small population of users. > > Yeah that was my thought when I saw pax/grsec beginning to be more > hostile to open source. That's not my call but the hardened team's, > however I'm all for removing these workarounds entirely if there's no > point in having them anymore. Is not only PaX/Grsec that don't allow textrel. SELinux do it to and that is manline kernel.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 2:13 PM Mike Gilbert wrote: > > On Tue, May 26, 2020 at 2:03 PM Alexis Ballier wrote: > > > > On Tue, 26 May 2020 10:45:39 -0400 > > Mike Gilbert wrote: > > > > Note that having the 'pic' useflag should be considered something > > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > > has the will to do it since this is mostly an issue on x86+pax, > > > > both being slowly decreasing. > > > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > > the grsecurity licensing issue, I wonder if there is any other good > > > reason to keep the "pic" USE flag today. Surely this affects a very > > > small population of users. > > > > > > I couldn't find any recent reference, but PIC shared libs used to be a > > QA policy. There's mainly two reasons to it: First is W^X enforcement; > > non PIC shared libs are refused by the x86_64 linker so a non-issue > > there, on x86 you need pax to emulate it because the mmu doesn't support > > the X part; I don't know about other arches. > > Then there is the small memory waste done because those libs will be > > loaded COW and thus their "code" is not shared anymore between > > processes. And the small startup performance hit to > > perform the relocations. > > > > The latter part affects everyone, and the rule of thumb for having a > > pic useflag (instead of always pic) is that the gain for non-pic asm is > > better than the loss of non-pic shared libs. This is subjective but > > usually a no-brainer for multimedia packages. > > Assuming that the pic performance penalty is really only relevant on > legacy arches (like x86), here are a couple of options: > > 1. Disable pic on arches where tie performance penalty is small. > 2. Force pic everywhere, performance be damned. Option 1 should say "Disable pic on arches where the performance penalty is large."
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 2:03 PM Alexis Ballier wrote: > > On Tue, 26 May 2020 10:45:39 -0400 > Mike Gilbert wrote: > > > Note that having the 'pic' useflag should be considered something > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > has the will to do it since this is mostly an issue on x86+pax, > > > both being slowly decreasing. > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > the grsecurity licensing issue, I wonder if there is any other good > > reason to keep the "pic" USE flag today. Surely this affects a very > > small population of users. > > > I couldn't find any recent reference, but PIC shared libs used to be a > QA policy. There's mainly two reasons to it: First is W^X enforcement; > non PIC shared libs are refused by the x86_64 linker so a non-issue > there, on x86 you need pax to emulate it because the mmu doesn't support > the X part; I don't know about other arches. > Then there is the small memory waste done because those libs will be > loaded COW and thus their "code" is not shared anymore between > processes. And the small startup performance hit to > perform the relocations. > > The latter part affects everyone, and the rule of thumb for having a > pic useflag (instead of always pic) is that the gain for non-pic asm is > better than the loss of non-pic shared libs. This is subjective but > usually a no-brainer for multimedia packages. Assuming that the pic performance penalty is really only relevant on legacy arches (like x86), here are a couple of options: 1. Disable pic on arches where tie performance penalty is small. 2. Force pic everywhere, performance be damned.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 26 May 2020 10:45:39 -0400 Mike Gilbert wrote: > > Note that having the 'pic' useflag should be considered something > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > has the will to do it since this is mostly an issue on x86+pax, > > both being slowly decreasing. > > Given that PaX has been stripped out of official Gentoo kernels due to > the grsecurity licensing issue, I wonder if there is any other good > reason to keep the "pic" USE flag today. Surely this affects a very > small population of users. I couldn't find any recent reference, but PIC shared libs used to be a QA policy. There's mainly two reasons to it: First is W^X enforcement; non PIC shared libs are refused by the x86_64 linker so a non-issue there, on x86 you need pax to emulate it because the mmu doesn't support the X part; I don't know about other arches. Then there is the small memory waste done because those libs will be loaded COW and thus their "code" is not shared anymore between processes. And the small startup performance hit to perform the relocations. The latter part affects everyone, and the rule of thumb for having a pic useflag (instead of always pic) is that the gain for non-pic asm is better than the loss of non-pic shared libs. This is subjective but usually a no-brainer for multimedia packages. This is probably something to bring up to QA too.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 26 May 2020 10:45:39 -0400 Mike Gilbert wrote: > > Note that having the 'pic' useflag should be considered something > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > has the will to do it since this is mostly an issue on x86+pax, > > both being slowly decreasing. > > Given that PaX has been stripped out of official Gentoo kernels due to > the grsecurity licensing issue, I wonder if there is any other good > reason to keep the "pic" USE flag today. Surely this affects a very > small population of users. > Yeah that was my thought when I saw pax/grsec beginning to be more hostile to open source. That's not my call but the hardened team's, however I'm all for removing these workarounds entirely if there's no point in having them anymore.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 5:30 AM Alexis Ballier wrote: > On Mon, 2020-05-25 at 21:09 -0400, Mike Gilbert wrote: > > If I understand you correctly, we should just drop the USE="pic" > > logic > > from the remaining packages that have it? Or are you trying to say > > something else? > > > Drop USE=asm unless there's a real reason to it: Such a useflag is, > IMHO, at the same level of a useflag on dev-lang/python that would > toggle dict's underlying implementations but not the semantics of the > language. > Have USE=pic for its historical meaning, aka, sacrificing everything to > have PIC shared libs because your system enforces this (pax). Thanks, this last sentence gives me a better understanding of why this "pic" USE flag exists at all. > Note that having the 'pic' useflag should be considered something to be > fixed: rewrite the asm in a PIC way. But these days nobody has the will > to do it since this is mostly an issue on x86+pax, both being slowly > decreasing. Given that PaX has been stripped out of official Gentoo kernels due to the grsecurity licensing issue, I wonder if there is any other good reason to keep the "pic" USE flag today. Surely this affects a very small population of users.
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
On Tue, May 26, 2020 at 4:12 AM Haelwenn (lanodan) Monnier wrote: > > [2020-05-25 23:41:23+0200] Piotr Karbowski: > > There are 3 common ways the xorg-server is started: > > > > - via XDM of some sort, usually forked as root, does not require suid, > > systemd or elogind. > > Launching X as root and having it be suid is quite the same thing… > Sort-of. An SUID X binary is a potential source of vulnerabilities even if you never run it, since it is still sitting there and ready to be exploited by somebody else. It also gives a user more control over how X is launched as root (command lines/control over stdin/out, etc). When X is launched as root by something the user doesn't control it reduces the attack surface somewhat. And if you never launch X11 at all it is just another unprivileged binary that can't do anything the user can't already do with system calls. In any case, setting suid on any binary is something that should only be done if there is no other practical solution. It certainly seems like this shouldn't be the default, especially if it is available for users to toggle if they wish. We can always put out a news item when this changes. If elogind is already enabled by default on a profile, then it doesn't make sense to ship X11 suid with that same profile when it isn't necessary. If a user wants to depart from the default config to not use elogind then they can just change the USE flag on xorg as well. -- Rich
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
[...] > > If I understand you correctly, we should just drop the USE="pic" > > logic > > from the remaining packages that have it? Or are you trying to say > > something else? > [...] > Note that having the 'pic' useflag should be considered something to > be > fixed: rewrite the asm in a PIC way. But these days nobody has the > will > to do it since this is mostly an issue on x86+pax, both being slowly > decreasing. As a side note on this: if USE=-pic has no textrel then obviously the useflag should be removed. This can happen over time if we don't pay enough attention.
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Piotr Karbowski wrote: > Hi, > > On 26/05/2020 00.34, Philip Webb wrote: >> I'ld rather you didn't. > You didn't provided any rationale for that. Running X as root is anti > pattern, especially nowadays when so little effort is required to not > have to run it as root. > > You can either enable elogind, or you can enable suid if you want to > preserve your status quo, we're talking here about defaults that user > can change if he has a reason to do so. > > -- Piotr. > As a user. [ebuild R ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo USE="elogind ipv6 libglvnd suid udev xorg -debug -dmx -doc -kdrive -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb" I don't recall the security issue that setting comes with. As a user, I'd rather defaults be secure and if I need to make a exception, then I can do so locally. I use elogin, used the other method until the recent change, so I likely don't need it set this way. If I understand this correctly, I'm going to disable suid and use the more secure method. I think it is reasonable since most likely, most users would expect the more secure method as a default and use a login tool that works with that setting. Those who use some other method, such as manually starting X, they still have the option to set it in whatever way works for them. I do agree with the point in another post that there should be some sort of notice about the change. One that is easily seen since it can cause problems. In the middle of typing, I made the change and ran into no problems so far. I restarted the GUI and logged in just fine. Just a users perspective. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 21:09 -0400, Mike Gilbert wrote: > On Mon, May 25, 2020 at 7:35 PM Alexis Ballier > wrote: > > On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > > > On Mon, May 25, 2020 at 3:18 PM Michał Górny > > > wrote: > > > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > > > On Mon, 25 May 2020 11:26:26 -0400 > > > > > Mike Gilbert wrote: > > > > > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > > > aball...@gentoo.org> > > > > > > wrote: > > > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > > > Author: Thomas Deutschmann gentoo > > > > > > > > > > > > > > > > org> > > > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > > > > > > > > > > > org> > > > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > > > URL: > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm > > > > > > > > was > > > > > > > > added, > > > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > > > whether > > > > > > > the toolchain produces PIC or not. Shared libs always > > > > > > > are, > > > > > > > and have > > > > > > > always been, built that way on Gentoo. > > > > > > > In this case, USE=pic means "no matter what it costs, I > > > > > > > do > > > > > > > not want > > > > > > > textrels", for the cases of hand written assembly that > > > > > > > has to > > > > > > > be > > > > > > > rewritten to support PIC. And, still in this case, this > > > > > > > costs > > > > > > > a lot > > > > > > > of performance, so it is enabled by default on hardened > > > > > > > profiles > > > > > > > and not others. > > > > > > > Textrels work fine (on some architectures), they disallow > > > > > > > W^X > > > > > > > and > > > > > > > force each process using the shared lib to make a "copy" > > > > > > > at > > > > > > > runtime > > > > > > > in order to resolve relocations, so are not desirable but > > > > > > > sometimes > > > > > > > the cost outweights the gain. > > > > > > > > > > > > > > Plus, profiles/features/hardened enables pic by default > > > > > > > but > > > > > > > knows > > > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > > > default USE > > > > > > value in the hardened profile should not drive decisions on > > > > > > what we > > > > > > name USE flags. > > > > > > > > > > ... but using a global well documented useflag instead of a > > > > > local > > > > > invention should drive such decisions. > > > > > > > > What 'global well documented useflag'? > > > > > > It's neither global, nor well-documented, but several packages do > > > define it locally. > > > > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba > > > > I guess this hasn't been really discussed back then. > > > > It is also used in a global way in profiles (make.defaults). > > > > > Personally, I think it should be renamed to "asm" or something > > > similar > > > in the majority of cases where it actually disables all use of > > > assembly code. > > > > Thankfully these days there's usually no need to disable asm to > > have > > pic. hardened has no mention of that flag, and I think that e.g. > > for > > openssl they would have noticed long ago. > > And again, 'asm' as a useflag makes no sense: if it works and > > simply > > replaces a C function by a faster one then it shouldn't even be an > > useflag. 'pic' on the other hand conveys the tradeoff idea. > > If I understand you correctly, we should just drop the USE="pic" > logic > from the remaining packages that have it? Or are you trying to say > something else? Drop USE=asm unless there's a real reason to it: Such a useflag is, IMHO, at the same level of a useflag on dev-lang/python that would toggle dict's underlying implementations but not the semantics of the language. Have USE=pic for its historical meaning, aka, sacrificing everything to have PIC shared libs because your system enforces this (pax). Note that having the 'pic' useflag should be considered something to be fixed: rewrite the asm in a PIC way. But these days nobody has the will to do it since this is mostly an issue on x86+pax, both being slowly decreasing.
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
[2020-05-25 23:41:23+0200] Piotr Karbowski: > There are 3 common ways the xorg-server is started: > > - via XDM of some sort, usually forked as root, does not require suid, > systemd or elogind. Launching X as root and having it be suid is quite the same thing… > - via better XDM that can into logind interface, started as regular user > thanks to logind interface provided by either systemd or elogind. > - via `startx`, if systemd or elogind are present, can work without > suid, without them, suid is required. btw I tried startx without suid a while ago, you can start it with your user in the right groups (input, video), which means that now every program that you run can snoop input devices and mess with your video outputs. And X couldn't properly manage DRM master control because you could set the DRM master but not drop it (kernel bug but "linux maintains bugs" and there is no capabilities to fix it, which could allow to avoid extra groups). I don't have something like elogind and likely will not as last time I looked at how it worked, it felt like reading about an unstable backdoor more than anything else. I'd rather have proper permissions in the kernel. > Flipping current '+suid (-)elogind' as *default* USE flags on ebuild > level into '+elogind (-)suid' will not affect first two use cases, and > affect only 3rd one if neither systemd is used, or elogind is enabled. > > What I'd like to go with is to enable elogind and disable suid on ebuild > level. The systemd profiles have use.mask for elogind, meaning it's not > a problem for them. and those who do not want to use any logind provider > can still opt-out out of it and go back to use suid. It shouldn't really > affect most of the users in any negative way, if anything, it will make > more users to not run Xorg as root, which is a positive aspect. > > The alternative way would be to enable elogind on default profile, > however it would also affect those who run headless Gentoo, of which a > lot refuse to use any login manager. > > So, dear people of Gentoo, what do you think about turning the current > possible opt-out of Xorg as root into possible opt-in for running Xorg > as root? People still will have a choice, just the defaults will be more > sane. I think you could have `xorg-server -suid` in the desktop profile, as you have elogingd there but on the ebuild level I'm not so sure. I'm not particularly against it but then should definitely come with a warning and it'll require users to notice the change and warning so they don't end up with a broken gentoo after an update.
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
Hi, On 26/05/2020 09.23, Philip Webb wrote: > 200526 Piotr Karbowski wrote: >> On 26/05/2020 00.34, Philip Webb wrote: >>> I'ld rather you didn't. >> You didn't provided any rationale for that. > > I thought I did (smile). > >> Running X as root is anti-pattern, especially nowadays >> when so little effort is required to not have to run it as root. > > I've never run X as root : it's not the UNIX way. I am not sure if you're trolling me here, or you genuinely not understand that regardless of what user you execute `startx` on, if Xorg have suid, it will start as root. >> You can either enable elogind > > Why would anyone want to abandon the long-successful UNIX method > & adopt some complex replacement ? I wouldn't call running X as root to be long successful UNIX method. Back in the days there was no way to ran X without root, now there is. >> or you can enable suid if you want to preserve your status quo, >> we're talking here about defaults >> that user can change if he has a reason to do so. > > Yes, this is a regular problem which is unavoidable : > what should the default be ? -- I want the default to be > what it's always been & what matches basic UNIX principles. > I can add 'suid' to 'xorg-server' in package.use , > but why should I have to ? -- over to you for a rationale (smile). I am not sure what kind of UNIX principles you're speaking about, the default should be reasonable, running X as root is not, if someone want to go against common sense and run X as root, he can do so, with defaults to not run it as root. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
On 5/22/20 9:08 PM, Michał Górny wrote: > Hence my question: do you find 'do not remove kernels listed > in bootloader config' feature useful? Do you think it should remain > the default? Do you think it is worthwhile to continue supporting it? In my Gentoo maintenance scripts I'm using eclean-kernel -n 2 Bootloader config is generated afterwards. signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] llvm.eclass: Fix prepending LLVM path before system paths
Do not prepend LLVM path before system path, in particular before
ccache/distcc paths. Instead, prepend it before the first LLVM version
found in PATH, or append to the end if no LLVM is found in PATH.
Closes: https://bugs.gentoo.org/627726
Signed-off-by: Michał Górny
---
eclass/llvm.eclass | 25 +++--
eclass/tests/llvm.sh | 16
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
index 4f968dc39f87..61b34d4985eb 100644
--- a/eclass/llvm.eclass
+++ b/eclass/llvm.eclass
@@ -198,8 +198,29 @@ llvm_pkg_setup() {
debug-print-function ${FUNCNAME} "${@}"
if [[ ${MERGE_TYPE} != binary ]]; then
- local llvm_prefix=$(get_llvm_prefix "${LLVM_MAX_SLOT}")
- export PATH=${llvm_prefix}/bin:${PATH}
+ local llvm_path=$(get_llvm_prefix "${LLVM_MAX_SLOT}")/bin
+ local IFS=:
+ local split_path=( ${PATH} )
+ local new_path=()
+ local x added=
+
+ # prepend new path before first LLVM version found
+ for x in "${split_path[@]}"; do
+ if [[ ${x} == */usr/lib/llvm/*/bin ]]; then
+ if [[ ${x} != ${llvm_path} ]]; then
+ new_path+=( "${llvm_path}" )
+ elif [[ ${added} && ${x} == ${llvm_path} ]];
then
+ # deduplicate
+ continue
+ fi
+ added=1
+ fi
+ new_path+=( "${x}" )
+ done
+ # ...or to the end of PATH
+ [[ ${added} ]] || new_path+=( "${llvm_path}" )
+
+ export PATH=${new_path[*]}
fi
}
diff --git a/eclass/tests/llvm.sh b/eclass/tests/llvm.sh
index bb8d5fc998e8..8527d81765dd 100755
--- a/eclass/tests/llvm.sh
+++ b/eclass/tests/llvm.sh
@@ -91,17 +91,17 @@ eindent
LLVM_MAX_SLOT=11 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH}:/usr/lib/llvm/11/bin \
- check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}:/usr/lib/llvm/11/bin"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/11/bin"
LLVM_MAX_SLOT=10 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH}:/usr/lib/llvm/11/bin:/usr/lib/llvm/10/bin \
- check_setup_path
"/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/11/bin:/usr/lib/llvm/10/bin"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/10/bin:/usr/lib/llvm/11/bin"
LLVM_MAX_SLOT=11 \
LLVM_INSTALLED_SLOT=10 \
PATH=${BASEPATH}:/usr/lib/llvm/10/bin \
- check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/10/bin"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/10/bin"
eoutdent
ebegin "Testing pkg_setup with the other LLVM version in PATH"
@@ -109,12 +109,12 @@ eindent
LLVM_MAX_SLOT=11 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH}:/usr/lib/llvm/10/bin \
- check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}:/usr/lib/llvm/10/bin"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/11/bin:/usr/lib/llvm/10/bin"
LLVM_MAX_SLOT=10 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH}:/usr/lib/llvm/11/bin \
- check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/11/bin"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/10/bin:/usr/lib/llvm/11/bin"
eoutdent
ebegin "Testing pkg_setup with LLVM missing from PATH"
@@ -122,17 +122,17 @@ eindent
LLVM_MAX_SLOT=11 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH} \
- check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/11/bin"
LLVM_MAX_SLOT=10 \
LLVM_INSTALLED_SLOT=1* \
PATH=${BASEPATH} \
- check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/10/bin"
LLVM_MAX_SLOT=11 \
LLVM_INSTALLED_SLOT=10 \
PATH=${BASEPATH} \
- check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}"
+ check_setup_path "${BASEPATH}:/usr/lib/llvm/10/bin"
eoutdent
texit
--
2.26.2
[gentoo-dev] [PATCH 1/3] llvm.eclass: Add initial tests
Signed-off-by: Michał Górny
---
eclass/tests/llvm.sh | 138 +++
1 file changed, 138 insertions(+)
create mode 100755 eclass/tests/llvm.sh
diff --git a/eclass/tests/llvm.sh b/eclass/tests/llvm.sh
new file mode 100755
index ..bb8d5fc998e8
--- /dev/null
+++ b/eclass/tests/llvm.sh
@@ -0,0 +1,138 @@
+#!/bin/bash
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+source tests-common.sh
+
+inherit llvm
+
+# llvm_check_deps override to disable has_version use.
+# in: ${LLVM_SLOT}
+# returns 0 if installed (i.e. == LLVM_INSTALLED_SLOT), 1 otherwise
+llvm_check_deps() {
+ [[ ${LLVM_SLOT} == ${LLVM_INSTALLED_SLOT} ]]
+}
+
+# check_prefix [...]
+# Check output of `get_llvm_prefix ...`.
+check_prefix() {
+ local expected=${1}
+ shift
+
+ tbegin "get_llvm_prefix ${*}; inst=${LLVM_INSTALLED_SLOT} ->
${expected}"
+ prefix=$(get_llvm_prefix "${@}")
+ [[ ${prefix} == ${expected} ]] ||
+ eerror "got: ${prefix} != exp: ${expected}"
+ tend ${?}
+}
+
+# check_setup_path
+# Check PATH after pkg_setup.
+check_setup_path() {
+ local expected=${1}
+ shift
+
+ tbegin "pkg_setup; max=${LLVM_MAX_SLOT}; inst=${LLVM_INSTALLED_SLOT} ->
PATH=${expected}"
+ path=$(llvm_pkg_setup; echo "${PATH}")
+ [[ ${path} == ${expected} ]] ||
+ eerror "got: ${path} != exp: ${expected}"
+ tend ${?}
+}
+
+
+EAPI=7
+BROOT=/broot
+SYSROOT=/sysroot
+ESYSROOT=/sysroot/eprefix
+ROOT=/root
+EROOT=/root/eprefix
+
+ebegin "Testing check_setup_path without max slot"
+eindent
+ LLVM_INSTALLED_SLOT=11 \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/11
+ LLVM_INSTALLED_SLOT=10 \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/10
+eoutdent
+
+ebegin "Testing check_setup_path with max slot"
+eindent
+ LLVM_INSTALLED_SLOT=1* \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/11 11
+ LLVM_INSTALLED_SLOT=1* \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/10 10
+ LLVM_INSTALLED_SLOT=10 \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/10 11
+eoutdent
+
+ebegin "Testing check_setup_path option switches"
+eindent
+ LLVM_INSTALLED_SLOT=11 \
+ check_prefix /broot/usr/lib/llvm/11 -b
+ LLVM_INSTALLED_SLOT=11 \
+ check_prefix /sysroot/eprefix/usr/lib/llvm/11 -d
+eoutdent
+
+ebegin "Testing check_setup_path EAPI 6 API"
+eindent
+ EAPI=6 \
+ LLVM_INSTALLED_SLOT=11 \
+ check_prefix /usr/lib/llvm/11 -d
+eoutdent
+
+BASEPATH=/usr/lib/ccache/bin:/usr/bin:/usr/sbin:/bin:/sbin
+
+# TODO: cross support?
+ESYSROOT=
+
+ebegin "Testing pkg_setup with all installed LLVM versions in PATH"
+eindent
+ LLVM_MAX_SLOT=11 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH}:/usr/lib/llvm/11/bin \
+ check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}:/usr/lib/llvm/11/bin"
+
+ LLVM_MAX_SLOT=10 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH}:/usr/lib/llvm/11/bin:/usr/lib/llvm/10/bin \
+ check_setup_path
"/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/11/bin:/usr/lib/llvm/10/bin"
+
+ LLVM_MAX_SLOT=11 \
+ LLVM_INSTALLED_SLOT=10 \
+ PATH=${BASEPATH}:/usr/lib/llvm/10/bin \
+ check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/10/bin"
+eoutdent
+
+ebegin "Testing pkg_setup with the other LLVM version in PATH"
+eindent
+ LLVM_MAX_SLOT=11 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH}:/usr/lib/llvm/10/bin \
+ check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}:/usr/lib/llvm/10/bin"
+
+ LLVM_MAX_SLOT=10 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH}:/usr/lib/llvm/11/bin \
+ check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}:/usr/lib/llvm/11/bin"
+eoutdent
+
+ebegin "Testing pkg_setup with LLVM missing from PATH"
+eindent
+ LLVM_MAX_SLOT=11 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH} \
+ check_setup_path "/usr/lib/llvm/11/bin:${BASEPATH}"
+
+ LLVM_MAX_SLOT=10 \
+ LLVM_INSTALLED_SLOT=1* \
+ PATH=${BASEPATH} \
+ check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}"
+
+ LLVM_MAX_SLOT=11 \
+ LLVM_INSTALLED_SLOT=10 \
+ PATH=${BASEPATH} \
+ check_setup_path "/usr/lib/llvm/10/bin:${BASEPATH}"
+eoutdent
+
+texit
--
2.26.2
[gentoo-dev] [PATCH 0/3] llvm.eclass: Fix prepending path and add tests
Hi, Here's a quick patch series that aims to fix prepending PATH to stop overriding distcc/ccache/etc. While at it, it adds some tests to the eclass. Please review. Michał Górny (3): llvm.eclass: Add initial tests llvm.eclass: Remove remnants of slot :0 support llvm.eclass: Fix prepending LLVM path before system paths eclass/llvm.eclass | 39 eclass/tests/llvm.sh | 138 +++ 2 files changed, 164 insertions(+), 13 deletions(-) create mode 100755 eclass/tests/llvm.sh -- 2.26.2
[gentoo-dev] [PATCH 2/3] llvm.eclass: Remove remnants of slot :0 support
Signed-off-by: Michał Górny
---
eclass/llvm.eclass | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
index a2da231b035a..4f968dc39f87 100644
--- a/eclass/llvm.eclass
+++ b/eclass/llvm.eclass
@@ -71,6 +71,10 @@ EXPORT_FUNCTIONS pkg_setup
if [[ ! ${_LLVM_ECLASS} ]]; then
+# make sure that the versions installing straight into /usr/bin
+# are uninstalled
+DEPEND="!!sys-devel/llvm:0"
+
# @ECLASS-VARIABLE: LLVM_MAX_SLOT
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -173,13 +177,6 @@ get_llvm_prefix() {
die "${FUNCNAME}: invalid max_slot=${max_slot}"
fi
- # fallback to :0
- # assume it's always <= 4 (the lower max_slot allowed)
- if has_version ${hv_switch} "sys-devel/llvm:0"; then
- echo "${prefix}/usr"
- return
- fi
-
die "No LLVM slot${1:+ <= ${1}} found installed!"
}
@@ -202,12 +199,7 @@ llvm_pkg_setup() {
if [[ ${MERGE_TYPE} != binary ]]; then
local llvm_prefix=$(get_llvm_prefix "${LLVM_MAX_SLOT}")
-
- # do not prepend /usr/bin, it's not necessary and breaks other
- # prepends, https://bugs.gentoo.org/622866
- if [[ ${llvm_prefix} != ${EPREFIX}/usr ]]; then
- export PATH=${llvm_prefix}/bin:${PATH}
- fi
+ export PATH=${llvm_prefix}/bin:${PATH}
fi
}
--
2.26.2
Re: [gentoo-dev] x11-base/xorg-server: No longer enabling suid by default.
200526 Piotr Karbowski wrote: > On 26/05/2020 00.34, Philip Webb wrote: >> I'ld rather you didn't. > You didn't provided any rationale for that. I thought I did (smile). > Running X as root is anti-pattern, especially nowadays > when so little effort is required to not have to run it as root. I've never run X as root : it's not the UNIX way. > You can either enable elogind Why would anyone want to abandon the long-successful UNIX method & adopt some complex replacement ? > or you can enable suid if you want to preserve your status quo, > we're talking here about defaults > that user can change if he has a reason to do so. Yes, this is a regular problem which is unavoidable : what should the default be ? -- I want the default to be what it's always been & what matches basic UNIX principles. I can add 'suid' to 'xorg-server' in package.use , but why should I have to ? -- over to you for a rationale (smile). Perhaps others can weigh in CAD 0,02 (choose your currency) at a time. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
