Re: [gentoo-dev] Python 3.10.0rc1
On Tue, 03 Aug 2021 11:15:13 +0200
Michał Górny wrote:
> Hi, everyone.
>
> Just a quick note: I've pushed Python 3.10.0rc1 today. It has many last
> minute changes that can break packages that were ported to previous
> 3.10.0 betas before.
>
> For practical reasons, we're going to support only >=3.10.0_rc1 going
> forward. If your package fails with >=3.10.0_rc1, feel free to apply
> fixes without caring for backwards compatibility with betas. If you see
> failures with 3.10.0_beta4, please try upgrading to _rc1 first.
>
> Notably, the newest releases of dev-python/django and dev-python/sphinx
> that I've pushed today were updated for _rc1 and will have failures with
> _beta4.
Should we drop PYTHON_COMPAT=python3_10 for known to break package versions?
For example latest stable dev-python/sphinx-4.0.3 did not like today's ~arch
python:
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.10/sphinx-build", line 33, in
sys.exit(load_entry_point('Sphinx==4.0.3', 'console_scripts',
'sphinx-build')())
File "/usr/lib/python-exec/python3.10/sphinx-build", line 25, in
importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 162, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3.10/site-packages/sphinx/cmd/build.py", line 25, in
from sphinx.application import Sphinx
File "/usr/lib/python3.10/site-packages/sphinx/application.py", line 31, in
from sphinx.config import Config
File "/usr/lib/python3.10/site-packages/sphinx/config.py", line 21, in
from sphinx.util import logging
File "/usr/lib/python3.10/site-packages/sphinx/util/__init__.py", line 41, in
from sphinx.util.typing import PathMatcher
File "/usr/lib/python3.10/site-packages/sphinx/util/typing.py", line 37, in
from types import Union as types_Union
ImportError: cannot import name 'Union' from 'types'
(/usr/lib/python3.10/types.py)
--
Sergei
[gentoo-dev] Packages up for grabs
Last batch of packages in search of a dedicated maintainer: app-emulation/ski app-misc/bb app-misc/golly dev-libs/editline dev-scheme/bytestructures dev-scheme/guile-gcrypt dev-scheme/guile-git dev-scheme/guile-sqlite3 dev-util/unifdef games-emulation/dolphin media-sound/xmms2 net-fs/curlftpfs sys-apps/prctl sys-boot/elilo sys-fs/libeatmydata www-client/lynx x11-misc/i3status x11-plugins/pidgin-window_merge x11-terms/cool-retro-term None of them should have any immediate problems. -- Sergei
Re: [gentoo-dev] Packages up to co-maintenance
On Fri, 30 Jul 2021 13:34:08 +0200 Florian Schmaus wrote: > It seems the list is missing dev-util/include-what-you-use, I'll assign > myself as maintainer. Sounds good. It should be in another batch: https://archives.gentoo.org/gentoo-dev/message/a911b62dfbb7532b2475594c8c32806c -- Sergei
[gentoo-dev] Packages up for grabs
Another batch of packages that would like a dedicated maintainer. I dropped myself from maintainer list for the following: app-editors/hteditor app-emulation/dosemu app-emulation/simh dev-lang/nasm dev-lang/squirrel dev-libs/libxls dev-util/poke dev-util/vbindiff Their state should be not be too broken but could always have an extra touch. -- Sergei
Re: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
On Sat, 17 Jul 2021 20:14:52 +0100 Sergei Trofimovich wrote: > On Thu, 8 Jul 2021 00:20:58 +0100 > Sergei Trofimovich wrote: > > > Tl;DR > > - > > > > libffi-3.4 entered ::gento without KEYWORDS today. > > After some testing it will be promoted into ~arch. > > > > libffi has two modes: > > 1. USE=-exec-static-trampoline: old (default, safe) > > 2. USE=exec-static-trampoline: new (cool, might expose latent bugs) > > Default USE=-exec-static-trampoline did not expose any new > failures over past week. > > If next week will be as calm we can unleash libffi into > ~arch next weekend (~24 July 2021). libffi-3.4.2 pushed to ~arch as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e03b5b8d5f1a5023dff4c341bb40578690471acb -- Sergei
Re: [gentoo-dev] Packages up for grabs
On Sat, 24 Jul 2021 19:20:16 +0200 Petr Vaněk wrote: > Hi, > > On Fri, Jul 23, 2021 at 11:31:59PM +0200, Haelwenn (lanodan) Monnier wrote: > > [2021-07-23 08:40:50+0100] Sergei Trofimovich: > > > dev-lang/elixir > > > dev-lang/erlang > > I am remaining dev-lang/erlang proxy-maintainer. I came to the package > approximately in the same time like Sergei, when I did few > contributions. Anyway, Sergei maintained the package really well and > meantime I stopped needing this package, therefore, I was about to drop > myself from metadata.xml past few months, but never did that. > > Probably question to Sergei or some other dev, should I do PR, where I > drop myself from erlang maintainers? I set erlang to maintainer-needed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37a7f224110019b127703919594332b40a1be559 and will unassign bugs from you. > > I could co-maintain these two, feel free to add me to metadata.xml, > > I'll look if there is some improvments that could be done but I haven't had > > to scratch an itch on it yet. > > New erlang version 24.0.4 has been released recently. Package version > bump is nice way how to start. > > Petr > -- Sergei
[gentoo-dev] Packages up for grabs
The packages could use some help from a dedicated maintainer. I dropped myself from maintainer list for the following: app-text/fbpdf dev-lang/crystal dev-lang/elixir dev-lang/erlang dev-lang/jwasm dev-libs/capstone dev-util/objconv dev-util/radare2 dev-util/shards dev-lang/gforth dev-util/xxdiff net-fs/smbnetfs Most of them require low/no maintenance. But there should be room for improvements over existing state. -- Sergei
Re: [gentoo-portage-dev] [PATCH] bin/estrip: avoid copying directories in FEATURES=installsources
On Sat, 17 Jul 2021 15:34:12 -0700
Zac Medico wrote:
> On 7/17/21 12:59 PM, Sergei Trofimovich wrote:
> > Initially problem is noticed on gcc-11 as a full ${WORKDIR} syncing
> > into /usr/src/debug. It happens because `debug.sources` sometimes
> > contains directory. For example on bash-5 it has:
> >
> > $ grep -zv '/<[^/>]*>$' debug.sources | LANG=C sort -z -u | sed -e
> > 's/\x00/\n/g'
> > bash-5.0/
> > bash-5.0/alias.c
> > ...
> >
> > This causes syncing object files, config.log, final binaries
> > and other unexpected data. The change avoids syncking paths
> > that end with '/'.
> >
> > Signed-off-by: Sergei Trofimovich
> > ---
> > bin/estrip | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/bin/estrip b/bin/estrip
> > index 7ef1ec35c..6cca0d04b 100755
> > --- a/bin/estrip
> > +++ b/bin/estrip
> > @@ -464,7 +464,10 @@ if [[ -s ${tmpdir}/debug.sources ]] && \
> > then
> > __vecho "installsources: rsyncing source files"
> > [[ -d ${D%/}/${prepstrip_sources_dir#/} ]] || mkdir -p
> > "${D%/}/${prepstrip_sources_dir#/}"
> > + # skip installation of ".../" (system headers? why inner slashes
> > are forbidden?)
> > + # skip syncing of ".../foo/" (complete directories)
> > grep -zv '/<[^/>]*>$' "${tmpdir}"/debug.sources | \
> > + grep -zv '/$' | \
> > (cd "${WORKDIR}"; LANG=C sort -z -u | \
> > rsync -tL0 --chmod=ugo-st,a+r,go-w,Da+x,Fa-x --files-from=-
> > "${WORKDIR}/" "${D%/}/${prepstrip_sources_dir#/}/" )
> >
> >
>
> Looks good. Merged with both grep calls combined via grep -e. Thanks!
>
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e083c8bf20d8488d329e3dccd643c28429e6fe30
TIL 'grep -e'! Thank you!
--
Sergei
pgprH8NkjP86o.pgp
Description: Цифровая подпись OpenPGP
[gentoo-portage-dev] [PATCH] bin/estrip: avoid copying directories in FEATURES=installsources
Initially problem is noticed on gcc-11 as a full ${WORKDIR} syncing
into /usr/src/debug. It happens because `debug.sources` sometimes
contains directory. For example on bash-5 it has:
$ grep -zv '/<[^/>]*>$' debug.sources | LANG=C sort -z -u | sed -e
's/\x00/\n/g'
bash-5.0/
bash-5.0/alias.c
...
This causes syncing object files, config.log, final binaries
and other unexpected data. The change avoids syncking paths
that end with '/'.
Signed-off-by: Sergei Trofimovich
---
bin/estrip | 3 +++
1 file changed, 3 insertions(+)
diff --git a/bin/estrip b/bin/estrip
index 7ef1ec35c..6cca0d04b 100755
--- a/bin/estrip
+++ b/bin/estrip
@@ -464,7 +464,10 @@ if [[ -s ${tmpdir}/debug.sources ]] && \
then
__vecho "installsources: rsyncing source files"
[[ -d ${D%/}/${prepstrip_sources_dir#/} ]] || mkdir -p
"${D%/}/${prepstrip_sources_dir#/}"
+ # skip installation of ".../" (system headers? why inner slashes
are forbidden?)
+ # skip syncing of ".../foo/" (complete directories)
grep -zv '/<[^/>]*>$' "${tmpdir}"/debug.sources | \
+ grep -zv '/$' | \
(cd "${WORKDIR}"; LANG=C sort -z -u | \
rsync -tL0 --chmod=ugo-st,a+r,go-w,Da+x,Fa-x --files-from=-
"${WORKDIR}/" "${D%/}/${prepstrip_sources_dir#/}/" )
--
2.32.0
Re: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
On Thu, 8 Jul 2021 00:20:58 +0100 Sergei Trofimovich wrote: > Tl;DR > - > > libffi-3.4 entered ::gento without KEYWORDS today. > After some testing it will be promoted into ~arch. > > libffi has two modes: > 1. USE=-exec-static-trampoline: old (default, safe) > 2. USE=exec-static-trampoline: new (cool, might expose latent bugs) Default USE=-exec-static-trampoline did not expose any new failures over past week. If next week will be as calm we can unleash libffi into ~arch next weekend (~24 July 2021). -- Sergei
[gentoo-dev] Re: [PATCH] pax-utils.eclass: allow EAPI=8
On Thu, 15 Jul 2021 10:58:17 +0100 Sergei Trofimovich wrote: > CC: harde...@gentoo.org > Closes: https://bugs.gentoo.org/802258 > Signed-off-by: Sergei Trofimovich > --- > eclass/pax-utils.eclass | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Pushed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=84b43bac4e545999e00c768bbcc908652eaf5502 -- Sergei
[gentoo-dev] [PATCH] pax-utils.eclass: allow EAPI=8
CC: harde...@gentoo.org
Closes: https://bugs.gentoo.org/802258
Signed-off-by: Sergei Trofimovich
---
eclass/pax-utils.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/pax-utils.eclass b/eclass/pax-utils.eclass
index 9c4903d24b6..f48dcdafe01 100644
--- a/eclass/pax-utils.eclass
+++ b/eclass/pax-utils.eclass
@@ -1,200 +1,200 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: pax-utils.eclass
# @MAINTAINER:
# The Gentoo Linux Hardened Team
# @AUTHOR:
# Author: Kevin F. Quinn
# Author: Anthony G. Basile
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: functions to provide PaX markings for hardened kernels
# @DESCRIPTION:
#
# This eclass provides support for manipulating PaX markings on ELF binaries,
# whether the system is using legacy PT_PAX markings or the newer XATTR_PAX.
# The eclass wraps the use of paxctl-ng, paxctl, set/getattr and scanelf
utilities,
# deciding which to use depending on what's installed on the build host, and
# whether we're working with PT_PAX, XATTR_PAX or both.
# Legacy PT_PAX markings no longer supported.
#
# To control what markings are made, set PAX_MARKINGS in /etc/portage/make.conf
# to contain either "PT", "XT" or "none". The default is none
case ${EAPI:-0} in
- [567]) ;;
+ 5|6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
if [[ -z ${_PAX_UTILS_ECLASS} ]]; then
_PAX_UTILS_ECLASS=1
# @ECLASS-VARIABLE: PAX_MARKINGS
# @DESCRIPTION:
# Control which markings are made:
# PT = PT_PAX markings, XT = XATTR_PAX markings
# Default to none markings.
PAX_MARKINGS=${PAX_MARKINGS:="none"}
# @FUNCTION: pax-mark
# @USAGE:
# @RETURN: Shell true if we succeed, shell false otherwise
# @DESCRIPTION:
# Marks with provided PaX
#
# Flags are passed directly to the utilities unchanged.
#
# @CODE
# p: disable PAGEEXEC P: enable PAGEEXEC
# e: disable EMUTRAMP E: enable EMUTRAMP
# m: disable MPROTECT M: enable MPROTECT
# r: disable RANDMMAP R: enable RANDMMAP
# s: disable SEGMEXEC S: enable SEGMEXEC
# @CODE
#
# Default flags are 'PeMRS', which are the most restrictive settings. Refer
# to https://pax.grsecurity.net/ for details on what these flags are all about.
#
# Please confirm any relaxation of restrictions with the Gentoo Hardened team.
# Either ask on the gentoo-hardened mailing list, or CC/assign
# harde...@gentoo.org on the bug report.
pax-mark() {
local f # loop
over paxables
local flags # pax
flags
local ret=0 #
overall return code of this function
# Only the actual PaX flags and z are accepted
# 1. The leading '-' is optional
# 2. -C -c only make sense for paxctl, but are unnecessary
#because we progressively do -q -qc -qC
# 3. z is allowed for the default
flags="${1//[!zPpEeMmRrSs]}"
[[ "${flags}" ]] || return 0
shift
# z = default. For XATTR_PAX, the default is no xattr field at all
local dodefault=""
[[ "${flags//[!z]}" ]] && dodefault="yes"
if has PT ${PAX_MARKINGS}; then
# Uncomment to list all files to be marked
# _pax_list_files einfo "$@"
for f in "$@"; do
# First try paxctl
if type -p paxctl >/dev/null; then
einfo "PT_PAX marking -${flags} ${f} with
paxctl"
# We try modifying the existing PT_PAX_FLAGS
header.
paxctl -q${flags} "${f}" >/dev/null 2>&1 &&
continue
# We no longer try to create/convert a
PT_PAX_FLAGS header, bug #590422
# paxctl -qC${flags} "${f}" >/dev/null 2>&1 &&
continue
# paxctl -qc${flags} "${f}" >/dev/null 2>&1 &&
continue
fi
# Next try paxctl-ng -> this will not create/convert
any program headers.
if type -p paxctl-ng >/dev/null && paxctl-ng -L ; then
einfo "PT_PAX marking -${flags} ${f} with
paxctl-ng"
flags="${flags//z}"
[[ ${dodefault} == "yes" ]] && paxctl-ng -L -z
"${f}" >/dev/null 2>&1
[gentoo-dev] Re: [PATCH 0/6] haskell eclass update to EAPI=8, old EAPI={0..5} removal
On Mon, 5 Jul 2021 23:25:50 +0100
Sergei Trofimovich wrote:
> The changes are mostly code removal. And example ebuild.
>
> Sergei Trofimovich (6):
> haskell-cabal.eclass: drop EAPI={0..5} support
> ghc-package.eclass: drop EAPI={0..5} support
> ghc-package.eclass: allow EAPI=8
> haskell-cabal.eclass: allow EAPI=8
> haskell-cabal.eclass: foo
> dev-haskell/c2hs: bump up to 0.28.8, EAPI=8 example
>
> dev-haskell/c2hs/Manifest | 1 +
> dev-haskell/c2hs/c2hs-0.28.8.ebuild | 41 +++
> eclass/ghc-package.eclass | 6 ++--
> eclass/haskell-cabal.eclass | 43 -
> 4 files changed, 56 insertions(+), 35 deletions(-)
> create mode 100644 dev-haskell/c2hs/c2hs-0.28.8.ebuild
Pushed to ::gentoo as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=891aa19d14688a95171dc6dcf14ce08d6ab237c5
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3feb01a7824b169ba1d35b997784c731fca9ac0f
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3cef7dc7c93537384dddf71cf96f57931467644d
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa8928997d917f74894c7013708c7c177a7bfa23
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fff0ee1b6c74df5f1598f5a2874fb67cfe09250b
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba01bd910d9667dbc7a1a80873ec3a23d897ed62
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df37ce46d2a17ed3c4225bce7c506931d98af59b
--
Sergei
Re: [gentoo-dev] [PATCH 1/5] haskell-cabal.eclass: drop EAPI={0..5} support
On Tue, 06 Jul 2021 09:34:14 +0200
Ulrich Mueller wrote:
> >>>>> On Tue, 06 Jul 2021, Sergei Trofimovich wrote:
>
> > case "${EAPI:-0}" in
>
> This could be just ${EAPI} now (and quotes were never necessary).
>
> > - 0|1) ;;
> > - 2|3|4|5|6|7) HASKELL_CABAL_EXPF+=" src_configure" ;;
> > + 6|7) ;;
> > *) die "EAPI ${EAPI} unsupported." ;;
>
>
> I'd suggest to update to die message to what is used in other eclasses
> (see toolchain-funcs.eclass for example):
>
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>
> > esac
>
> Same comment for the other eclasses of this series.
>
> Ulrich
Sounds good. Done both as:
--- a/eclass/haskell-cabal.eclass
+++ b/eclass/haskell-cabal.eclass
@@ -40,11 +40,11 @@
# FEATURE can be removed once
https://github.com/haskell/cabal/issues/7213
# is fixed.
-case "${EAPI:-0}" in
+case ${EAPI} in
# eutils is for eqawarn
6|7) inherit eutils ;;
8) ;;
- *) die "EAPI ${EAPI} unsupported." ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
inherit ghc-package multilib toolchain-funcs
--
Sergei
pgpf8CE1FGmnS.pgp
Description: Цифровая подпись OpenPGP
[gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
Tl;DR - libffi-3.4 entered ::gento without KEYWORDS today. After some testing it will be promoted into ~arch. libffi has two modes: 1. USE=-exec-static-trampoline: old (default, safe) 2. USE=exec-static-trampoline: new (cool, might expose latent bugs) +toralf@ (CC): Toralf, can we set a tinderbox run for [1.] >=dev-libs/libffi-3.4[-exec-static-trampoline] case? [2.] would also be nice: >=dev-libs/libffi-3.4[exec-static-trampoline] My worry is that it will generate a lot of collateral breakage (at least some percentage of dev-haskell/*). Tracker: https://bugs.gentoo.org/801109 Known examples: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4 More help - If you happen to maintain a Gentoo package that uses libffi you can try libffi-3.4 early to see how it behaves. - Try [1.] on packages you maintain. - If you are brave try [2.] as well but be ready to recover your system! A few packages are already known to be affected: https://wiki.gentoo.org/index.php?title=Project:Toolchain#libffi-3.4 Add new bugs you found as blockers to the libffi-3.4 tracker: https://bugs.gentoo.org/801109 More words -- In this release most probably impactful change is a trampoline code handling change. Before 3.4 libffi generated all code at runtime in a single executable chunk of executable memory. Since 3.4 libffi uses does not use runtime code generation and uses statically defined trampoline in a very clever way: https://sourceware.org/pipermail/libffi-discuss/2021/002579.html This should not be a problem for most applications, but two are already known to fail: - ghc: https://gitlab.haskell.org/ghc/ghc/-/issues/20051 - gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/283 The symptoms are SIGSEGVs and erratic behaviour. To workaround widespread breakage libffi-3.4 provides a fallback mode that reuses libffi-3.3 style trampoline layout via USE=-exec-static-trampoline. Also note that libffi-3.4 also changes SONAME from libffi.so.7 to libffi.so.8. It will rebuild a few packages as a result. It's a good time to check for missing rebuild slot operator in depends. If you broke your system with USE=exec-static-trampoline try to recover with USE=-exec-static-trampoline first. It should avoid rebuilding revdeps back to .so.7. Debugging help -- If you suspect your package is affected then CC toolchain@ to the relevant bug and we'll try to sort it out together. Have fun! -- Sergei
[gentoo-dev] [PATCH 3/5] ghc-package.eclass: allow EAPI=8
Signed-off-by: Sergei Trofimovich
---
eclass/ghc-package.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/ghc-package.eclass b/eclass/ghc-package.eclass
index 71e84af3444..e91fb2912f6 100644
--- a/eclass/ghc-package.eclass
+++ b/eclass/ghc-package.eclass
@@ -1,346 +1,346 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ghc-package.eclass
# @MAINTAINER:
# "Gentoo's Haskell Language team"
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 6 7 8
# @AUTHOR:
# Original Author: Andres Loeh
# @BLURB: This eclass helps with the Glasgow Haskell Compiler's package
configuration utility.
# @DESCRIPTION:
# Helper eclass to handle ghc installation/upgrade/deinstallation process.
inherit multiprocessing
# Maintain version-testing compatibility with ebuilds not using EAPI 7.
case "${EAPI:-0}" in
- 7) ;;
+ 7|8) ;;
6) inherit eapi7-ver ;;
*) die "EAPI ${EAPI} unsupported." ;;
esac
# GHC uses it's own native code generator. Portage's
# QA check generates false positive because it assumes
# presence of GCC-specific sections.
#
# Workaround false positiove by disabling the check completely.
# bug #722078, bug #677600
QA_FLAGS_IGNORED='.*'
# @FUNCTION: ghc-getghc
# @DESCRIPTION:
# returns the name of the ghc executable
ghc-getghc() {
if ! type -P ${HC:-ghc}; then
ewarn "ghc not found"
type -P false
fi
}
# @FUNCTION: ghc-getghcpkg
# @INTERNAL
# @DESCRIPTION:
# Internal function determines returns the name of the ghc-pkg executable
ghc-getghcpkg() {
if ! type -P ${HC_PKG:-ghc-pkg}; then
ewarn "ghc-pkg not found"
type -P false
fi
}
# @FUNCTION: ghc-getghcpkgbin
# @DESCRIPTION:
# returns the name of the ghc-pkg binary (ghc-pkg
# itself usually is a shell script, and we have to
# bypass the script under certain circumstances);
# for Cabal, we add an empty global package config file,
# because for some reason the global package file
# must be specified
ghc-getghcpkgbin() {
local empty_db="${T}/empty.conf.d" ghc_pkg="$(ghc-libdir)/bin/ghc-pkg"
if [[ ! -d ${empty_db} ]]; then
"${ghc_pkg}" init "${empty_db}" || die "Failed to initialize
empty global db"
fi
echo "$(ghc-libdir)/bin/ghc-pkg" "--global-package-db=${empty_db}"
}
# @FUNCTION: ghc-version
# @DESCRIPTION:
# returns upstream version of ghc
# as reported by '--numeric-version'
# Examples: "7.10.2", "7.9.20141222"
_GHC_VERSION_CACHE=""
ghc-version() {
if [[ -z "${_GHC_VERSION_CACHE}" ]]; then
_GHC_VERSION_CACHE="$($(ghc-getghc) --numeric-version)"
fi
echo "${_GHC_VERSION_CACHE}"
}
# @FUNCTION: ghc-pm-version
# @DESCRIPTION:
# returns package manager(PM) version of ghc
# as reported by '$(best_version)'
# Examples: "PM:7.10.2", "PM:7.10.2_rc1", "PM:7.8.4-r4"
_GHC_PM_VERSION_CACHE=""
ghc-pm-version() {
local pm_ghc_p
if [[ -z "${_GHC_PM_VERSION_CACHE}" ]]; then
pm_ghc_p=$(best_version dev-lang/ghc)
_GHC_PM_VERSION_CACHE="PM:${pm_ghc_p#dev-lang/ghc-}"
fi
echo "${_GHC_PM_VERSION_CACHE}"
}
# @FUNCTION: ghc-cabal-version
# @DESCRIPTION:
# return version of the Cabal library bundled with ghc
ghc-cabal-version() {
# outputs in format: 'version: 1.18.1.5'
set -- `$(ghc-getghcpkg)
--package-db=$(ghc-libdir)/package.conf.d.initial field Cabal version`
echo "$2"
}
# @FUNCTION: ghc-is-dynamic
# @DESCRIPTION:
# checks if ghc is built against dynamic libraries
# binaries linked against GHC library (and using plugin loading)
# have to be linked the same way:
#https://ghc.haskell.org/trac/ghc/ticket/10301
ghc-is-dynamic() {
$(ghc-getghc) --info | grep "GHC Dynamic" | grep -q "YES"
}
# @FUNCTION: ghc-supports-shared-libraries
# @DESCRIPTION:
# checks if ghc is built with support for building
# shared libraries (aka '-dynamic' option)
ghc-supports-shared-libraries() {
$(ghc-getghc) --info | grep "RTS ways" | grep -q "dyn"
}
# @FUNCTION: ghc-supports-threaded-runtime
# @DESCRIPTION:
# checks if ghc is built with support for threaded
# runtime (aka '-threaded' option)
ghc-supports-threaded-runtime() {
$(ghc-getghc) --info | grep "RTS ways" | grep -q "thr"
}
# @FUNCTION: ghc-supports-smp
# @DESCRIPTION:
# checks if ghc is built with support for multiple cores runtime
ghc-supports-smp() {
$(ghc-getghc) --info | grep "Support SMP&quo
[gentoo-dev] [PATCH 5/5] dev-haskell/c2hs: bump up to 0.28.8, EAPI=8 example
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: Sergei Trofimovich
---
dev-haskell/c2hs/Manifest | 1 +
dev-haskell/c2hs/c2hs-0.28.8.ebuild | 41 +
2 files changed, 42 insertions(+)
create mode 100644 dev-haskell/c2hs/c2hs-0.28.8.ebuild
diff --git a/dev-haskell/c2hs/Manifest b/dev-haskell/c2hs/Manifest
index ea522395f4f..17502636930 100644
--- a/dev-haskell/c2hs/Manifest
+++ b/dev-haskell/c2hs/Manifest
@@ -1 +1,2 @@
DIST c2hs-0.28.7.tar.gz 207782 BLAKE2B
a9f29506e6aaec3400d844ad85b2a6b6e1b87cb3c6c641665ab6bc5465903da8c2c82c3511b451e54cf30dfac61092dd323f8a2af48b5daa6081a4e9c5f00c9d
SHA512
69c877349ae4864763d20664edae07a67aa1c55f5d4fccc3fcb6d06e94eb14d6b4b0201fc2840a9ebbc45a2a21ab55ad0e79f9cd88c3df67abf5c1fd62d6
+DIST c2hs-0.28.8.tar.gz 207816 BLAKE2B
6d912fd93c6076ccd86ed62e075f1addb7b44378c82acc0cbaf04b6b91a2ed4530cde60a9139316d928a2867474bafde5c14aedb4ab9e78e5faaa99830276a71
SHA512
ff9119acecddd853f2f797385f971c249bcd92d4b141e8e7ea5f5d3e63aa257502c80ded2720a46e3186260026b94c9e518f08f8e452a64c9f888d0183ee1749
diff --git a/dev-haskell/c2hs/c2hs-0.28.8.ebuild
b/dev-haskell/c2hs/c2hs-0.28.8.ebuild
new file mode 100644
index 000..38703f4aa68
--- /dev/null
+++ b/dev-haskell/c2hs/c2hs-0.28.8.ebuild
@@ -0,0 +1,41 @@
+# Copyright 1999-2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+# ebuild generated by hackport 0.6.7.
+
+CABAL_FEATURES="test-suite"
+inherit haskell-cabal
+
+DESCRIPTION="C->Haskell FFI tool that gives some cross-language type safety"
+HOMEPAGE="https://github.com/haskell/c2hs;
+SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="regression"
+
+RESTRICT=test # needs unprefixed 'cpp'
+
+RDEPEND="dev-haskell/dlist:=
+ >=dev-haskell/language-c-0.7.1:= =dev-lang/ghc-8.4.3:=
+ regression? ( >=dev-haskell/shelly-1.9.0:= =dev-haskell/yaml-0.8:= )
+"
+DEPEND="${RDEPEND}
+ >=dev-haskell/cabal-2.2.0.1
+ test? ( dev-haskell/hunit
+ dev-haskell/test-framework
+ dev-haskell/test-framework-hunit
+ !regression? ( >=dev-haskell/shelly-1.9.0
[gentoo-dev] [PATCH 4/5] haskell-cabal.eclass: allow EAPI=8
Signed-off-by: Sergei Trofimovich
---
eclass/haskell-cabal.eclass | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/eclass/haskell-cabal.eclass b/eclass/haskell-cabal.eclass
index f7a6d35e610..a858ddea3ec 100644
--- a/eclass/haskell-cabal.eclass
+++ b/eclass/haskell-cabal.eclass
@@ -1,757 +1,759 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: haskell-cabal.eclass
# @MAINTAINER:
# Haskell herd
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 6 7 8
# @AUTHOR:
# Original author: Andres Loeh
# Original author: Duncan Coutts
# @BLURB: for packages that make use of the Haskell Common Architecture for
Building Applications and Libraries (cabal)
# @DESCRIPTION:
# Basic instructions:
#
# Before inheriting the eclass, set CABAL_FEATURES to
# reflect the tools and features that the package makes
# use of.
#
# Currently supported features:
# haddock-- for documentation generation
# hscolour -- generation of colourised sources
# hoogle -- generation of documentation search index
# profile-- if package supports to build profiling-enabled libraries
# bootstrap -- only used for the cabal package itself
# lib-- the package installs libraries
# nocabaldep -- don't add dependency on cabal.
# only used for packages that _must_ not pull the dependency
# on cabal, but still use this eclass (e.g. haskell-updater).
# ghcdeps-- constraint dependency on package to ghc onces
# only used for packages that use libghc internally and _must_
# not pull upper versions
# test-suite -- add support for cabal test-suites (introduced in Cabal-1.8)
# rebuild-after-doc-workaround -- enable doctest test failue workaround.
# Symptom: when `./setup haddock` is run in a `build-type:
Custom`
# package it might cause cause the test-suite to fail with
# errors like:
# > : cannot satisfy -package-id
singletons-2.7-3Z7pnljD8tU1NrslJodXmr
# Workaround re-reginsters the package to avoid the failure
# (and rebuilds changes).
# FEATURE can be removed once
https://github.com/haskell/cabal/issues/7213
# is fixed.
-inherit eutils ghc-package multilib toolchain-funcs
+case "${EAPI:-0}" in
+ # eutils is for eqawarn
+ 6|7) inherit eutils ;;
+ 8) ;;
+ *) die "EAPI ${EAPI} unsupported." ;;
+esac
+
+inherit ghc-package multilib toolchain-funcs
+
+EXPORT_FUNCTIONS pkg_setup src_configure src_compile src_test src_install
pkg_postinst pkg_postrm
# @ECLASS-VARIABLE: CABAL_EXTRA_CONFIGURE_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup configure'.
# example: /etc/portage/make.conf:
#CABAL_EXTRA_CONFIGURE_FLAGS="--enable-shared --enable-executable-dynamic"
: ${CABAL_EXTRA_CONFIGURE_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_EXTRA_BUILD_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup build'.
# example: /etc/portage/make.conf: CABAL_EXTRA_BUILD_FLAGS=-v
: ${CABAL_EXTRA_BUILD_FLAGS:=}
# @ECLASS-VARIABLE: GHC_BOOTSTRAP_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters for ghc when building
# _only_ 'setup' binary bootstrap.
# example: /etc/portage/make.conf: GHC_BOOTSTRAP_FLAGS=-dynamic to make
# linking 'setup' faster.
: ${GHC_BOOTSTRAP_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_EXTRA_HADDOCK_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup haddock'.
# example: /etc/portage/make.conf:
#CABAL_EXTRA_HADDOCK_FLAGS="--haddock-options=--latex
--haddock-options=--pretty-html"
: ${CABAL_EXTRA_HADDOCK_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_EXTRA_HOOGLE_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup haddock --hoogle'.
# example: /etc/portage/make.conf:
#CABAL_EXTRA_HOOGLE_FLAGS="--haddock-options=--show-all"
: ${CABAL_EXTRA_HOOGLE_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_EXTRA_HSCOLOUR_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup hscolour'.
# example: /etc/portage/make.conf:
#CABAL_EXTRA_HSCOLOUR_FLAGS="--executables --tests"
: ${CABAL_EXTRA_HSCOLOUR_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_EXTRA_TEST_FLAGS
# @USER_VARIABLE
# @DESCRIPTION:
# User-specified additional parameters passed to 'setup test'.
# example: /etc/portage/make.conf:
#CABAL_EXTRA_TEST_FLAGS="-v3 --show-details=streaming"
: ${CABAL_EXTRA_TEST_FLAGS:=}
# @ECLASS-VARIABLE: CABAL_DEBUG_LOOSENING
# @DESCRIPTION:
# Show debug output for 'cabal_chdeps' function if set.
#
[gentoo-dev] [PATCH 2/5] ghc-package.eclass: drop EAPI={0..5} support
Signed-off-by: Sergei Trofimovich
---
eclass/ghc-package.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/ghc-package.eclass b/eclass/ghc-package.eclass
index 5decbaa228e..71e84af3444 100644
--- a/eclass/ghc-package.eclass
+++ b/eclass/ghc-package.eclass
@@ -1,346 +1,346 @@
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ghc-package.eclass
# @MAINTAINER:
# "Gentoo's Haskell Language team"
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 6 7
# @AUTHOR:
# Original Author: Andres Loeh
# @BLURB: This eclass helps with the Glasgow Haskell Compiler's package
configuration utility.
# @DESCRIPTION:
# Helper eclass to handle ghc installation/upgrade/deinstallation process.
inherit multiprocessing
# Maintain version-testing compatibility with ebuilds not using EAPI 7.
case "${EAPI:-0}" in
- 0|1|2|3|7) ;;
- 4|5|6) inherit eapi7-ver ;;
+ 7) ;;
+ 6) inherit eapi7-ver ;;
*) die "EAPI ${EAPI} unsupported." ;;
esac
# GHC uses it's own native code generator. Portage's
# QA check generates false positive because it assumes
# presence of GCC-specific sections.
#
# Workaround false positiove by disabling the check completely.
# bug #722078, bug #677600
QA_FLAGS_IGNORED='.*'
# @FUNCTION: ghc-getghc
# @DESCRIPTION:
# returns the name of the ghc executable
ghc-getghc() {
if ! type -P ${HC:-ghc}; then
ewarn "ghc not found"
type -P false
fi
}
# @FUNCTION: ghc-getghcpkg
# @INTERNAL
# @DESCRIPTION:
# Internal function determines returns the name of the ghc-pkg executable
ghc-getghcpkg() {
if ! type -P ${HC_PKG:-ghc-pkg}; then
ewarn "ghc-pkg not found"
type -P false
fi
}
# @FUNCTION: ghc-getghcpkgbin
# @DESCRIPTION:
# returns the name of the ghc-pkg binary (ghc-pkg
# itself usually is a shell script, and we have to
# bypass the script under certain circumstances);
# for Cabal, we add an empty global package config file,
# because for some reason the global package file
# must be specified
ghc-getghcpkgbin() {
local empty_db="${T}/empty.conf.d" ghc_pkg="$(ghc-libdir)/bin/ghc-pkg"
if [[ ! -d ${empty_db} ]]; then
"${ghc_pkg}" init "${empty_db}" || die "Failed to initialize
empty global db"
fi
echo "$(ghc-libdir)/bin/ghc-pkg" "--global-package-db=${empty_db}"
}
# @FUNCTION: ghc-version
# @DESCRIPTION:
# returns upstream version of ghc
# as reported by '--numeric-version'
# Examples: "7.10.2", "7.9.20141222"
_GHC_VERSION_CACHE=""
ghc-version() {
if [[ -z "${_GHC_VERSION_CACHE}" ]]; then
_GHC_VERSION_CACHE="$($(ghc-getghc) --numeric-version)"
fi
echo "${_GHC_VERSION_CACHE}"
}
# @FUNCTION: ghc-pm-version
# @DESCRIPTION:
# returns package manager(PM) version of ghc
# as reported by '$(best_version)'
# Examples: "PM:7.10.2", "PM:7.10.2_rc1", "PM:7.8.4-r4"
_GHC_PM_VERSION_CACHE=""
ghc-pm-version() {
local pm_ghc_p
if [[ -z "${_GHC_PM_VERSION_CACHE}" ]]; then
pm_ghc_p=$(best_version dev-lang/ghc)
_GHC_PM_VERSION_CACHE="PM:${pm_ghc_p#dev-lang/ghc-}"
fi
echo "${_GHC_PM_VERSION_CACHE}"
}
# @FUNCTION: ghc-cabal-version
# @DESCRIPTION:
# return version of the Cabal library bundled with ghc
ghc-cabal-version() {
# outputs in format: 'version: 1.18.1.5'
set -- `$(ghc-getghcpkg)
--package-db=$(ghc-libdir)/package.conf.d.initial field Cabal version`
echo "$2"
}
# @FUNCTION: ghc-is-dynamic
# @DESCRIPTION:
# checks if ghc is built against dynamic libraries
# binaries linked against GHC library (and using plugin loading)
# have to be linked the same way:
#https://ghc.haskell.org/trac/ghc/ticket/10301
ghc-is-dynamic() {
$(ghc-getghc) --info | grep "GHC Dynamic" | grep -q "YES"
}
# @FUNCTION: ghc-supports-shared-libraries
# @DESCRIPTION:
# checks if ghc is built with support for building
# shared libraries (aka '-dynamic' option)
ghc-supports-shared-libraries() {
$(ghc-getghc) --info | grep "RTS ways" | grep -q "dyn"
}
# @FUNCTION: ghc-supports-threaded-runtime
# @DESCRIPTION:
# checks if ghc is built with support for threaded
# runtime (aka '-threaded' option)
ghc-supports-threaded-runtime() {
$(ghc-getghc) --info | grep "RTS ways" | grep -q "thr"
}
# @FUNCTION: ghc-supports-smp
# @DESCRIPTION:
# checks if ghc is built with support for multiple cores runtime
ghc-supports-smp() {
[gentoo-dev] [PATCH 0/6] haskell eclass update to EAPI=8, old EAPI={0..5} removal
The changes are mostly code removal. And example ebuild.
Sergei Trofimovich (6):
haskell-cabal.eclass: drop EAPI={0..5} support
ghc-package.eclass: drop EAPI={0..5} support
ghc-package.eclass: allow EAPI=8
haskell-cabal.eclass: allow EAPI=8
haskell-cabal.eclass: foo
dev-haskell/c2hs: bump up to 0.28.8, EAPI=8 example
dev-haskell/c2hs/Manifest | 1 +
dev-haskell/c2hs/c2hs-0.28.8.ebuild | 41 +++
eclass/ghc-package.eclass | 6 ++--
eclass/haskell-cabal.eclass | 43 -
4 files changed, 56 insertions(+), 35 deletions(-)
create mode 100644 dev-haskell/c2hs/c2hs-0.28.8.ebuild
--
2.32.0
Re: [gentoo-dev] Packages up for grabs (m-n batch)
On Fri, 2 Jul 2021 10:08:09 +0100 Marek Szuba wrote: > On 2021-07-02 08:41, Sergei Trofimovich wrote: > > # maybe retire? it somewhat worked a while ago > > x11-plugins/purple-mattermost > > Seconding retirement, maybe I kept doing something wrong but I had no > luck getting this to work with recent versions of Mattermost within the > last ~1.5 years. Done as: # Sergei Trofimovich (2021-07-02) # Outdated, not really maintained. Grab it if you like. # Masked for removal in 30 days. bug #800097. x11-plugins/purple-mattermost -- Sergei
[gentoo-dev] Packages up to co-maintenance
I welcome everyone to co-maintain or completely take over maintenance from me of the packages I maintain. As it became apparent I'm not a great maintainer. I'll keep providing basic life support for packages nobody else is interested in. Here is the package list (some packages have second maintainer): app-editors/hteditor app-emulation/dosemu app-emulation/simh app-emulation/ski app-misc/bb app-misc/golly app-misc/mc app-text/fbpdf app-text/lv dev-lang/crystal dev-lang/elixir dev-lang/erlang dev-lang/gforth dev-lang/jwasm dev-lang/mmix dev-lang/nasm dev-lang/squirrel dev-libs/capstone dev-libs/editline dev-libs/libxls dev-scheme/bytestructures dev-scheme/guile-gcrypt dev-scheme/guile-git dev-scheme/guile-json dev-scheme/guile-sqlite3 dev-util/ltrace dev-util/objconv dev-util/poke dev-util/radare2 dev-util/re2c dev-util/shards dev-util/unifdef dev-util/vbindiff dev-util/xxdiff games-emulation/dolphin media-fonts/terminus-font media-libs/aalib media-sound/xmms2 net-fs/curlftpfs net-fs/smbnetfs net-ftp/proftpd sys-apps/prctl sys-block/seekwatcher sys-boot/elilo sys-fs/libeatmydata sys-fs/mtpfs www-client/lynx x11-misc/i3status x11-misc/xclip x11-misc/xsri x11-plugins/pidgin-window_merge x11-terms/cool-retro-term -- Sergei
[gentoo-dev] Packages up for grabs (m-n batch)
I don't use these any more. # should be low maintenance overhead. a rare dependency: app-arch/pax # fuzzer tools of sorts, very fun ones: app-forensics/honggfuzz sys-libs/blocksruntime app-forensics/radamsa app-forensics/zzuf # ollydbg-style ineteractive debugger if you are into that kind # of stuff: dev-util/edb-debugger # C++ headers cleaner dev-util/include-what-you-use # CVS repo conversion tools dev-vcs/cvs-fast-export dev-vcs/cvsps # maybe retire? it somewhat worked a while ago x11-plugins/purple-mattermost # needs someone who is mildly passionate in nim dev-lang/nim # bumps weekly, relatively small wrapper around # a ton of backend tools. Needs some test suite love. dev-util/diffoscope # needs quite a bit love: sys-fs/diskdev_cmds sys-fs/hfsutils -- Sergei
Re: [gentoo-dev] 'pax_kernel' USE flag
On Wed, 23 Jun 2021 10:46:00 +0100 Marek Szuba wrote: > On 2021-06-22 19:01, Sergei Trofimovich wrote: > > > One of the steps forward for libffi would be to add extra USE=pax-kernel > > with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent. > > Sounds like a good idea to me, that way people who don't pay attention > to news items will notice. It's now part of libffi-3.4_rc1: # If you are USE=pax_kernel user you really want USE=pax-kernel as well. # That's a flag rename: https://archives.gentoo.org/gentoo-dev/message/273f5ec9ebc8075f6ee8d8cdda9e759e REQUIRED_USE="pax_kernel? ( pax-kernel )" https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0b2c89773e0df20c0c770b6d8620564b76468578 -- Sergei
[gentoo-dev] Re: darcs.eclass removal?
On Wed, 23 Jun 2021 20:49:47 +0200 Ulrich Mueller wrote: > https://qa-reports.gentoo.org/output/eapi-per-eclass/darcs.eclass/ > says that there are no consumers left. There are two references worth cleaning up to avoid possible future confusion: $ git grep darcs | fgrep inherit net-misc/mico/mico-2.3.13-r13.ebuild: inherit darcs net-misc/mico/mico-2.3.13-r14.ebuild: inherit darcs > So, could the eclass be removed? Sounds fine. Done as https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1432ea2f94ed0d176ac7301884f806e64e568eee --- a/eclass/darcs.eclass +++ b/eclass/darcs.eclass @@ -1,6 +1,9 @@ # Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 +# @DEAD +# No consumers left. Removal in 30 days. + # @ECLASS: darcs.eclass # @MAINTAINER: # "Gentoo's Haskell Language team" -- Sergei
Re: [gentoo-dev] 'pax_kernel' USE flag
On Tue, 22 Jun 2021 10:35:12 +0100 Marek Szuba wrote: > Dear everyone, > > Seeing as in the end this USE flag is not going anywhere in spite of > Gentoo no longer providing PaX-capable kernel sources, could we please > rename it (e.g. to 'pax-kernel') so that it no longer contains a > disallowed character. I understand the main reason this hasn't been done > yet is that we expected it might disappear altogether. Just renaming pax_kernel to pax-kernel for dev-libs/libffi will likely brick a system on W^X kernel on first world update. python will probably start crashing instantly. Unless user explicitly notices that they need to enable a new flag. Other packages should be less problematic to just switch over. One of the steps forward for libffi would be to add extra USE=pax-kernel with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent. The specifics should ideally be handled by hardened@ team. Otherwise we can do 'use pax_kernel || die' libffi experiment if nobody objects. Say, in a few days. -- Sergei
Re: [gentoo-dev] [PATCH 6/8] flag-o-matic.eclass: Support EAPI 8
On Mon, 21 Jun 2021 18:49:32 +0200
Ulrich Müller wrote:
> Signed-off-by: Ulrich Müller
> ---
> eclass/flag-o-matic.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index 2e04e2acb06b..d262a60b6bb2 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -4,7 +4,7 @@
> # @ECLASS: flag-o-matic.eclass
> # @MAINTAINER:
> # toolch...@gentoo.org
> -# @SUPPORTED_EAPIS: 5 6 7
> +# @SUPPORTED_EAPIS: 5 6 7 8
> # @BLURB: common functions to manipulate and query toolchain flags
> # @DESCRIPTION:
> # This eclass contains a suite of functions to help developers sanely
> @@ -12,7 +12,7 @@
>
> case ${EAPI:-0} in
> 0|1|2|3|4) die "flag-o-matic.eclass: EAPI ${EAPI} is too old." ;;
> - 5|6|7) ;;
> + 5|6|7|8) ;;
> *) die "EAPI ${EAPI} is not supported by flag-o-matic.eclass." ;;
> esac
>
> --
> 2.32.0
>
>
Looks good.
--
Sergei
Re: [gentoo-dev] [PATCH 4/8] multilib.eclass: Update a comment
On Mon, 21 Jun 2021 18:49:30 +0200
Ulrich Müller wrote:
> Reported-by: Sam James
> Signed-off-by: Ulrich Müller
> ---
> eclass/multilib.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 8422d5e18499..67cad9875a12 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -519,7 +519,7 @@ multilib_toolchain_setup() {
> fi
>
> if [[ ${ABI} != ${DEFAULT_ABI} ]] ; then
> - # Back that multilib-ass up so we can restore it later
> + # Backup multilib state so we can restore it later
> for v in "${save_restore_variables[@]}" ; do
> vv="_abi_saved_${v}"
> [[ ${!v+set} == "set" ]] && export ${vv}="${!v}" ||
> unset ${vv}
> --
> 2.32.0
>
>
Looks good.
--
Sergei
Re: [gentoo-dev] [PATCH 3/8] multilib.eclass: Support EAPI 8
On Mon, 21 Jun 2021 18:49:29 +0200
Ulrich Müller wrote:
> Signed-off-by: Ulrich Müller
> ---
> eclass/multilib.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 6ba820229de3..8422d5e18499 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -4,14 +4,14 @@
> # @ECLASS: multilib.eclass
> # @MAINTAINER:
> # toolch...@gentoo.org
> -# @SUPPORTED_EAPIS: 5 6 7
> +# @SUPPORTED_EAPIS: 5 6 7 8
> # @BLURB: This eclass is for all functions pertaining to handling multilib
> configurations.
> # @DESCRIPTION:
> # This eclass is for all functions pertaining to handling multilib
> configurations.
>
> case ${EAPI:-0} in
> # EAPI=0 is still used by crossdev, bug #797367
> - [0567]) ;;
> + 0|5|6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> --
> 2.32.0
>
>
Looks good.
--
Sergei
Re: [gentoo-dev] [PATCH 2/8] toolchain-funcs.eclass: Support EAPI 8
On Mon, 21 Jun 2021 18:49:28 +0200
Ulrich Müller wrote:
> Signed-off-by: Ulrich Müller
> ---
> eclass/toolchain-funcs.eclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 1643f64cab76..563d9deef40b 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -4,7 +4,7 @@
> # @ECLASS: toolchain-funcs.eclass
> # @MAINTAINER:
> # Toolchain Ninjas
> -# @SUPPORTED_EAPIS: 5 6 7
> +# @SUPPORTED_EAPIS: 5 6 7 8
> # @BLURB: functions to query common info about the toolchain
> # @DESCRIPTION:
> # The toolchain-funcs aims to provide a complete suite of functions
> @@ -15,7 +15,7 @@
>
> case ${EAPI:-0} in
> # EAPI=0 is still used by crossdev, bug #797367
> - [0567]) ;;
> + 0|5|6|7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> --
> 2.32.0
>
>
Looks good.
--
Sergei
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: include riscv bitness in tc-arch
On Sun, 02 May 2021 18:22:43 -0400
fedora@gmail.com wrote:
> This makes tc-arch identify RISC-V systems as either "riscv64" or
> "riscv32". It will still return "riscv" for the kernel arch or if
> bitness is not given in the host triplet.
tc-arch returns portage's ARCH= value based on passed tuple.
There are no ARCH=riscv32 or ARCH=riscv64 in Gentoo. Only ARCH=riscv.
You probably need to map gentoo's ABI USE to upstream's ABI flag.
But it's not clear from your description what effect you intend to achieve.
> This fixes the expected values of cpu_family in meson projects:
> https://mesonbuild.com/Reference-tables.html#cpu-families
I'm not sure what meson's `cpu_family` is. Is it something that should
affect -march=/-mabi=? Please state your intent explicitly. The fix does
not look correct.
> Signed-off-by: David Michael
> ---
>
> Hi,
>
> When building systemd from Git, it now relies on the "stable" cpu_family
> value for riscv64[0]. Meson gets this value from tc-arch. From a quick
> grep, it looked like the only place that compared tc-arch output with
> "riscv" was toolchain.eclass, but there may be some other subtle issue I
> haven't encountered. Does this look okay to apply?
>
> Thanks.
>
> David
>
> [0]
> https://github.com/systemd/systemd/commit/a00ff2e1b596f0d08d32b8ca9cefe8aca1212604
>
> eclass/toolchain-funcs.eclass | 10 +-
> eclass/toolchain.eclass | 2 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 267cf5cfce3..5dd6dcbd658 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -687,7 +687,15 @@ ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ;
> }
> echo ppc
> fi
> ;;
> - riscv*) echo riscv;;
> + riscv*)
> + if [[ ${type} != "kern" && ${host} == riscv32* ]] ; then
> + echo riscv32
> + elif [[ ${type} != "kern" && ${host} == riscv64* ]] ;
> then
> + echo riscv64
> + else
> + echo riscv
> + fi
> + ;;
> s390*) echo s390;;
> score*) echo score;;
> sh64*) ninj sh64 sh;;
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index f41ce22c591..b1d2e671917 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1084,7 +1084,7 @@ toolchain_src_configure() {
> # https://gcc.gnu.org/PR93157
> [[ ${CTARGET} == powerpc64-*-musl ]] && confgcc+=(
> --with-abi=elfv2 )
> ;;
> - riscv)
> + riscv*)
> # Add --with-abi flags to set default ABI
> confgcc+=( --with-abi=$(gcc-abi-map ${TARGET_DEFAULT_ABI}) )
> ;;
> --
> 2.26.3
>
>
--
Sergei
[gentoo-dev] gcc-11 enters ~arch tree
Today gcc-11.1.0 released upstream and was added to ::gentoo as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc068d96fb49e308456cbe944fb29b1f78e6ad5c User-visible changes are nicely described in upstream porting doc: https://gcc.gnu.org/gcc-11/porting_to.html A few highlights I personally encountered are: - use -std=gnu++17 instead of -std=gnu++14 - ordered pointer comparison with integer (like int *p; 'p > 0') - dynamic exception specifications - gcc now enforces that comparison objects be invocable as const - header dependency changes On top of that: - -fipa-modref (enabled by default) might expose latent bugs in existing programs. -fno-ipa-modref should be a quick hack to check the hypothesis. Failures don't look widespread, thus gcc-11 should be fine to use as a default compiler. Check out known bugs and workarounds on gcc-11 tracker: https://bugs.gentoo.org/show_bug.cgi?id=gcc-11 Gentoo Toolchain wiki page for common fixes (nothing there so far): https://wiki.gentoo.org/wiki/Project:Toolchain#gcc-11 As usual if you can't figure out what is wrong with your package pull in toolchain@ to the bug and we'll get to the bottom of it. Good luck! -- Sergei
Re: [gentoo-dev] [PATCH] toolchain.eclass: Drop eutils in >=EAPI-8, add some missing || die
On Wed, 07 Apr 2021 00:16:46 +0200
Andreas Sturmlechner wrote:
> Just some cheap fixes while flag-o-matic.eclass causes cache-regen anyway.
This eclass is used by 4 packages. Cache hit is not an issue.
> See also: https://github.com/gentoo/gentoo/pull/20207
>
> - Add inherit guard.
> - Fix eclassdoc a bit.
>
> ---
> eclass/toolchain.eclass | 51 +++--
> 1 file changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index f41ce22c591..e7fae3aad5a 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -1,14 +1,37 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> -# Maintainer: Toolchain Ninjas
> +# @ECLASS: toolchain.eclass
> +# @MAINTAINER:
> +# Toolchain Ninjas
> # @SUPPORTED_EAPIS: 5 6 7
> +# @BLURB: Functions to build sys-devel/gcc
> +# @DESCRIPTION:
> +# Comprehensive helper and phase functions to build sys-devel/gcc and
> +# adjacent packages, support for release and live ebuilds.
It's worth to explicitly list all packages supported by the eclass.
Which is:
dev-lang/gnat-gpl
sys-devel/kgcc64
sys-devel/gcc
sys-devel/gcc-apple
and their cross-*/ variants.
> +# This eclass unconditionally inherits toolchain-funcs.eclass and all its
> public
> +# variables and helper functions may be considered as part of this eclass's
> API.
It inherits many other eclasses. None of them should be considered
toolchain.eclass's API. I don't think any ebuilds rely on it. If they do it's a
bug.
> +# This eclass's phase functions are not intended to be mixed and matched, so
> if
> +# any phase functions are overridden, the toolchain.eclass version should
> also
> +# be called.
> +
> +case ${EAPI:-0} in
> + 0|1|2|3|4*) die "Need to upgrade to at least EAPI=5" ;;
> + 5*|6) inherit eapi7-ver eutils ;;
> + 7) inherit eutils ;;
> + *) die "I don't speak EAPI ${EAPI}." ;;
> +esac
Why these inherits go before the guard?
> +if [[ -z ${_TOOLCHAIN_ECLASS} ]]; then
> +_TOOLCHAIN_ECLASS=1
Why does this eclass need a guard? 'toolchain.eclass' is not something
you include lightly.
> +inherit flag-o-matic gnuconfig libtool multilib pax-utils toolchain-funcs
> prefix
>
> DESCRIPTION="The GNU Compiler Collection"
> HOMEPAGE="https://gcc.gnu.org/;
>
> -inherit eutils flag-o-matic gnuconfig libtool multilib pax-utils
> toolchain-funcs prefix
> -
> tc_is_live() {
> [[ ${PV} == ** ]]
> }
> @@ -27,13 +50,6 @@ fi
>
> FEATURES=${FEATURES/multilib-strict/}
>
> -case ${EAPI:-0} in
> - 0|1|2|3|4*) die "Need to upgrade to at least EAPI=5" ;;
> - 5*|6) inherit eapi7-ver ;;
> - 7) ;;
> - *) die "I don't speak EAPI ${EAPI}." ;;
> -esac
> -
> EXPORT_FUNCTIONS pkg_pretend pkg_setup src_unpack src_prepare src_configure \
> src_compile src_test src_install pkg_postinst pkg_postrm
>
> @@ -525,7 +541,7 @@ toolchain_src_prepare() {
> || eerror "Please file a bug about this"
> eend $?
> done
> - sed -i 's|A-Za-z0-9|[:alnum:]|g' "${S}"/gcc/*.awk #215828
> + sed -i 's|A-Za-z0-9|[:alnum:]|g' "${S}"/gcc/*.awk || die #215828
All '|| die' should be a separate commit. Feel free to push that now.
> # Prevent new texinfo from breaking old versions (see #198182, #464008)
> if tc_version_is_at_least 4.1; then
> @@ -639,17 +655,16 @@ make_gcc_hard() {
> # than ALL_CFLAGS...
> sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
> -e 's|^ALL_CFLAGS = |ALL_CFLAGS = $(HARD_CFLAGS) |' \
> - -i "${S}"/gcc/Makefile.in
> + -i "${S}"/gcc/Makefile.in || die
> # Need to add HARD_CFLAGS to ALL_CXXFLAGS on >= 4.7
> if tc_version_is_at_least 4.7 ; then
> sed -e '/^ALL_CXXFLAGS/iHARD_CFLAGS = ' \
> -e 's|^ALL_CXXFLAGS = |ALL_CXXFLAGS = $(HARD_CFLAGS) |'
> \
> - -i "${S}"/gcc/Makefile.in
> + -i "${S}"/gcc/Makefile.in || die
> fi
> - sed -i \
> - -e "/^HARD_CFLAGS = /s|=|= ${gcc_hard_flags} |" \
> - "${S}"/gcc/Makefile.in || die
> + sed -e "/^HARD_CFLAGS = /s|=|= ${gcc_hard_flags} |" \
> + -i "${S}"/gcc/Makefile.in || die
This should be a separate commit. Feel free to push that now.
> }
>
> @@ -2434,3 +2449,5 @@ toolchain_death_notice() {
> # Thus safer way to enable/disable the feature is to rely on implicit
> # enabled-by-default state:
> #econf $(usex foo '' --disable-foo)
> +
> +fi
> --
> 2.31.1
--
Sergei
Re: [gentoo-dev] [PATCH v2 5/5] flag-o-matic.eclass: get rid of eutils in
On Thu, 01 Apr 2021 12:02:15 +0200
Andreas Sturmlechner wrote:
> From af002023d6b8f9a9e51fc31c8c25d48012e35ddf Mon Sep 17 00:00:00 2001
> From: Andreas Sturmlechner
> Date: Sun, 28 Mar 2021 15:04:50 +0200
> Subject: [PATCH 5/5] flag-o-matic.eclass: Fix eclassdoc
>
> Signed-off-by: Andreas Sturmlechner
The patch looks good.
> ---
> eclass/flag-o-matic.eclass | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index a35f0bef269..6e7582c4643 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -21,6 +21,8 @@ case ${EAPI} in
> *) die "EAPI ${EAPI} is not supported by flag-o-matic.eclass." ;;
> esac
>
> +# @FUNCTION: all-flag-vars
> +# @DESCRIPTION:
> # Return all the flag variables that our high level funcs operate on.
> all-flag-vars() {
> echo {ADA,C,CPP,CXX,CCAS,F,FC,LD}FLAGS
> @@ -108,7 +110,10 @@ _setup-allowed-flags() {
> )
> }
>
> -# inverted filters for hardened compiler. This is trying to unpick
> +# @FUNCTION: _filter-hardened
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Inverted filters for hardened compiler. This is trying to unpick
> # the hardened compiler defaults.
> _filter-hardened() {
> local f
> @@ -142,6 +147,9 @@ _filter-hardened() {
> done
> }
>
> +# @FUNCTION: _filter-var
> +# @INTERNAL
> +# @DESCRIPTION:
> # Remove occurrences of strings from variable given in $1
> # Strings removed are matched as globs, so for example
> # '-O*' would remove -O1, -O2 etc.
> @@ -334,6 +342,11 @@ replace-cpu-flags() {
> return 0
> }
>
> +# @FUNCTION: _is_flagq
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is in a given , else returns shell
> false.
> _is_flagq() {
> local x var="$1[*]"
> for x in ${!var} ; do
> --
> 2.31.0
>
--
Sergei
pgpSdirhDXgag.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH v2 4/5] flag-o-matic.eclass: get rid of eutils in
On Thu, 01 Apr 2021 12:01:24 +0200
Andreas Sturmlechner wrote:
> From 797d26ad9fe861c9c332f54a0f856a17af32ee53 Mon Sep 17 00:00:00 2001
> From: Andreas Sturmlechner
> Date: Wed, 31 Mar 2021 00:29:55 +0200
> Subject: [PATCH 4/5] flag-o-matic.eclass: Make test-flags-PROG() internal
>
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/flag-o-matic.eclass | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index e4fdfd0b62d..a35f0bef269 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -598,7 +598,25 @@ test-flag-FC() { _test-flag-PROG "FC" f95 "$@"; }
> # Returns shell true if is supported by the C compiler and linker,
> else returns shell false.
> test-flag-CCLD() { _test-flag-PROG "CC" c+ld "$@"; }
>
> +# @FUNCTION: test-flags-PROG
> +# @USAGE: [more flags...]
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if are supported by given ,
> +# else returns shell false.
> test-flags-PROG() {
> + [[ ${EAPI} == [5-7] ]] ||
'[[ ${EAPI} == [567] ]] ||'. Otherwise patch looks ok.
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
> + _test-flags-PROG
> +}
> +
> +# @FUNCTION: _test-flags-PROG
> +# @USAGE: [more flags...]
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if are supported by given ,
> +# else returns shell false.
> +_test-flags-PROG() {
> local comp=$1
> local flags=()
> local x
> @@ -635,31 +653,31 @@ test-flags-PROG() {
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if are supported by the C compiler, else
> returns shell false.
> -test-flags-CC() { test-flags-PROG "CC" "$@"; }
> +test-flags-CC() { _test-flags-PROG "CC" "$@"; }
>
> # @FUNCTION: test-flags-CXX
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if are supported by the C++ compiler, else
> returns shell false.
> -test-flags-CXX() { test-flags-PROG "CXX" "$@"; }
> +test-flags-CXX() { _test-flags-PROG "CXX" "$@"; }
>
> # @FUNCTION: test-flags-F77
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if are supported by the Fortran 77 compiler,
> else returns shell false.
> -test-flags-F77() { test-flags-PROG "F77" "$@"; }
> +test-flags-F77() { _test-flags-PROG "F77" "$@"; }
>
> # @FUNCTION: test-flags-FC
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if are supported by the Fortran 90 compiler,
> else returns shell false.
> -test-flags-FC() { test-flags-PROG "FC" "$@"; }
> +test-flags-FC() { _test-flags-PROG "FC" "$@"; }
>
> # @FUNCTION: test-flags-CCLD
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if are supported by the C compiler and default
> linker, else returns shell false.
> -test-flags-CCLD() { test-flags-PROG "CCLD" "$@"; }
> +test-flags-CCLD() { _test-flags-PROG "CCLD" "$@"; }
>
> # @FUNCTION: test-flags
> # @USAGE:
> --
> 2.31.0
>
--
Sergei
pgp2FJQCfhNCe.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH v2 3/5] flag-o-matic.eclass: get rid of eutils in
On Thu, 01 Apr 2021 11:59:48 +0200
Andreas Sturmlechner wrote:
> From 7b063ec3f4e2a76c43cd5de8a81a0a30c0f87a6d Mon Sep 17 00:00:00 2001
> From: Andreas Sturmlechner
> Date: Wed, 31 Mar 2021 00:27:27 +0200
> Subject: [PATCH 3/5] flag-o-matic.eclass: Make test-flag-PROG() internal
>
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/flag-o-matic.eclass | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index d511a140592..e4fdfd0b62d 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -459,7 +459,25 @@ strip-flags() {
> return 0
> }
>
> +# @FUNCTION: test-flag-PROG
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is supported by given ,
> +# else returns shell false.
> test-flag-PROG() {
> + [[ ${EAPI} == [5-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
Yeah. Given that we use tc-get$1 in implementation it's not easy to
use as is in external code. Patch is ok. We can consider it later.
> + _test-flag-PROG
> +}
> +
> +# @FUNCTION: _test-flag-PROG
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is supported by given ,
> +# else returns shell false.
> +_test-flag-PROG() {
> local comp=$1
> local lang=$2
> shift 2
> @@ -554,31 +572,31 @@ test-flag-PROG() {
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the C compiler, else returns
> shell false.
> -test-flag-CC() { test-flag-PROG "CC" c "$@"; }
> +test-flag-CC() { _test-flag-PROG "CC" c "$@"; }
>
> # @FUNCTION: test-flag-CXX
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the C++ compiler, else
> returns shell false.
> -test-flag-CXX() { test-flag-PROG "CXX" c++ "$@"; }
> +test-flag-CXX() { _test-flag-PROG "CXX" c++ "$@"; }
>
> # @FUNCTION: test-flag-F77
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the Fortran 77 compiler, else
> returns shell false.
> -test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
> +test-flag-F77() { _test-flag-PROG "F77" f77 "$@"; }
>
> # @FUNCTION: test-flag-FC
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the Fortran 90 compiler, else
> returns shell false.
> -test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
> +test-flag-FC() { _test-flag-PROG "FC" f95 "$@"; }
>
> # @FUNCTION: test-flag-CCLD
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the C compiler and linker,
> else returns shell false.
> -test-flag-CCLD() { test-flag-PROG "CC" c+ld "$@"; }
> +test-flag-CCLD() { _test-flag-PROG "CC" c+ld "$@"; }
>
> test-flags-PROG() {
> local comp=$1
> --
> 2.31.0
>
--
Sergei
pgpfuGQRt2RUi.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH v2 2/5] flag-o-matic.eclass: get rid of eutils in
On Thu, 01 Apr 2021 11:58:07 +0200
Andreas Sturmlechner wrote:
> From 6d1c665d06186dde5361905d5fb2057e044b040e Mon Sep 17 00:00:00 2001
> From: Andreas Sturmlechner
> Date: Wed, 31 Mar 2021 00:22:12 +0200
> Subject: [PATCH 2/5] flag-o-matic.eclass: Make setup-allowed-flags() internal
>
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/flag-o-matic.eclass | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index ab79f70392d..d511a140592 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -26,9 +26,23 @@ all-flag-vars() {
> echo {ADA,C,CPP,CXX,CCAS,F,FC,LD}FLAGS
> }
>
> +# @FUNCTION: setup-allowed-flags
> +# @INTERNAL
> +# @DESCRIPTION:
> # {C,CPP,CXX,CCAS,F,FC,LD}FLAGS that we allow in strip-flags
> # Note: shell globs and character lists are allowed
> setup-allowed-flags() {
> + [[ ${EAPI} == [5-7] ]] ||
Minor nit: I'd prefer '[[ ${EAPI} == [567] ]]'
Otherwise the patch is ok.
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
> + _setup-allowed-flags
> +}
> +
> +# @FUNCTION: _setup-allowed-flags
> +# @INTERNAL
> +# @DESCRIPTION:
> +# {C,CPP,CXX,CCAS,F,FC,LD}FLAGS that we allow in strip-flags
> +# Note: shell globs and character lists are allowed
> +_setup-allowed-flags() {
> ALLOWED_FLAGS=(
> -pipe -O '-O[12sg]' -mcpu -march -mtune
> '-fstack-protector*' '-fsanitize*' '-fstack-check*'
> -fno-stack-check
> @@ -412,7 +426,7 @@ strip-flags() {
> local x y var
>
> local ALLOWED_FLAGS
> - setup-allowed-flags
> + _setup-allowed-flags
>
> set -f # disable pathname expansion
>
> --
> 2.31.0
>
--
Sergei
pgpJn1wjBmoDr.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH v2 1/5] flag-o-matic.eclass: get rid of eutils in
On Thu, 01 Apr 2021 11:57:01 +0200
Andreas Sturmlechner wrote:
> From 0bdac63ac30fdbe2d1293d0ecbdbc2a5ea673112 Mon Sep 17 00:00:00 2001
> From: Andreas Sturmlechner
> Date: Sun, 28 Mar 2021 11:41:32 +0200
> Subject: [PATCH 1/5] flag-o-matic.eclass: SUPPORTED_EAPIS: 5,6,7; drop eutils,
> multilib
>
> - eutils was only used for eqawarn in old EAPI
> - multilib usage unknown, but is inherited by toolchain-funcs anyway
>
> Signed-off-by: Andreas Sturmlechner
> ---
> eclass/flag-o-matic.eclass | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index 20ee39d98ba..ab79f70392d 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -1,9 +1,10 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: flag-o-matic.eclass
> # @MAINTAINER:
> # toolch...@gentoo.org
> +# @SUPPORTED_EAPIS: 5 6 7
> # @BLURB: common functions to manipulate and query toolchain flags
> # @DESCRIPTION:
> # This eclass contains a suite of functions to help developers sanely
> @@ -12,7 +13,13 @@
> if [[ -z ${_FLAG_O_MATIC_ECLASS} ]]; then
> _FLAG_O_MATIC_ECLASS=1
>
> -inherit eutils toolchain-funcs multilib
> +inherit toolchain-funcs
> +
> +case ${EAPI} in
> + [0-4]) die "flag-o-matic.eclass: EAPI ${EAPI} is too old." ;;
> + [5-7]) inherit eutils ;;
> + *) die "EAPI ${EAPI} is not supported by flag-o-matic.eclass." ;;
> +esac
Minor nit: I'd prefer more typical '|' style for string enumerations.
case ${EAPI:-0} in
0|1|2|3|4) ...
5|6|7) ...
Otherwise patch is good.
> # Return all the flag variables that our high level funcs operate on.
> all-flag-vars() {
> --
> 2.31.0
>
--
Sergei
pgpOTNHgOZnhK.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in
On Wed, 31 Mar 2021 09:45:52 +0200 Andreas Sturmlechner wrote: > On Mittwoch, 31. März 2021 09:33:21 CEST Sergei Trofimovich wrote: > > On Wed, 31 Mar 2021 08:39:27 +0200 > > > > > > See also: > > > https://qa-reports.gentoo.org/output/eapi-per-eclass/eutils.eclass/ > > > https://github.com/gentoo/gentoo/pull/20207 > > > > Please post series as separate patches. > > > > They are separate in the linked PR, if you need to check that they are a > proper series. I planned to provide review in this mailing list. -- Sergei pgpIhf6sCiiZn.pgp Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in
On Wed, 31 Mar 2021 08:39:27 +0200
Andreas Sturmlechner wrote:
> qa-reports showing >7300 ebuilds with EAPI-7 using eutils.eclass, that can't
> be right.
>
> - Restrict inherit eutils to - Drop bogus multilib.eclass (inherited by toolchain-funcs.eclass anyway)
> - Several functions look like they should be internal
> - Fix eclassdoc issues, add missing docu
>
> See also:
> https://qa-reports.gentoo.org/output/eapi-per-eclass/eutils.eclass/
> https://github.com/gentoo/gentoo/pull/20207
Please post series as separate patches.
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index 20ee39d98ba..35dc09f94de 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2020 Gentoo Authors
> +# Copyright 1999-2021 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: flag-o-matic.eclass
> @@ -12,16 +12,37 @@
> if [[ -z ${_FLAG_O_MATIC_ECLASS} ]]; then
> _FLAG_O_MATIC_ECLASS=1
>
> -inherit eutils toolchain-funcs multilib
> +inherit toolchain-funcs
>
> +case ${EAPI} in
> + [0-7]) inherit eutils ;;
> + *) ;;
> +esac
> +
> +# @FUNCTION: all-flag-vars
> +# @DESCRIPTION:
> # Return all the flag variables that our high level funcs operate on.
> all-flag-vars() {
> echo {ADA,C,CPP,CXX,CCAS,F,FC,LD}FLAGS
> }
>
> +# @FUNCTION: setup-allowed-flags
> +# @INTERNAL
> +# @DESCRIPTION:
> # {C,CPP,CXX,CCAS,F,FC,LD}FLAGS that we allow in strip-flags
> # Note: shell globs and character lists are allowed
> setup-allowed-flags() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
> + _setup-allowed-flags
> +}
> +
> +# @FUNCTION: _setup-allowed-flags
> +# @INTERNAL
> +# @DESCRIPTION:
> +# {C,CPP,CXX,CCAS,F,FC,LD}FLAGS that we allow in strip-flags
> +# Note: shell globs and character lists are allowed
> +_setup-allowed-flags() {
> ALLOWED_FLAGS=(
> -pipe -O '-O[12sg]' -mcpu -march -mtune
> '-fstack-protector*' '-fsanitize*' '-fstack-check*'
> -fno-stack-check
> @@ -87,7 +108,10 @@ setup-allowed-flags() {
> )
> }
>
> -# inverted filters for hardened compiler. This is trying to unpick
> +# @FUNCTION: _filter-hardened
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Inverted filters for hardened compiler. This is trying to unpick
> # the hardened compiler defaults.
> _filter-hardened() {
> local f
> @@ -121,6 +145,9 @@ _filter-hardened() {
> done
> }
>
> +# @FUNCTION: _filter-var
> +# @INTERNAL
> +# @DESCRIPTION:
> # Remove occurrences of strings from variable given in $1
> # Strings removed are matched as globs, so for example
> # '-O*' would remove -O1, -O2 etc.
> @@ -313,6 +340,11 @@ replace-cpu-flags() {
> return 0
> }
>
> +# @FUNCTION: _is_flagq
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is in a given , else returns shell
> false.
> _is_flagq() {
> local x var="$1[*]"
> for x in ${!var} ; do
> @@ -405,7 +437,7 @@ strip-flags() {
> local x y var
>
> local ALLOWED_FLAGS
> - setup-allowed-flags
> + _setup-allowed-flags
>
> set -f # disable pathname expansion
>
> @@ -438,7 +470,23 @@ strip-flags() {
> return 0
> }
>
> +# @FUNCTION: test-flag-PROG
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is supported by given , else
> returns shell false.
> test-flag-PROG() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
> + _test-flag-PROG
> +}
> +
> +# @FUNCTION: _test-flag-PROG
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is supported by given , else
> returns shell false.
> +_test-flag-PROG() {
> local comp=$1
> local lang=$2
> shift 2
> @@ -533,33 +581,49 @@ test-flag-PROG() {
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the C compiler, else returns
> shell false.
> -test-flag-CC() { test-flag-PROG "CC" c "$@"; }
> +test-flag-CC() { _test-flag-PROG "CC" c "$@"; }
>
> # @FUNCTION: test-flag-CXX
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the C++ compiler, else
> returns shell false.
> -test-flag-CXX() { test-flag-PROG "CXX" c++ "$@"; }
> +test-flag-CXX() { _test-flag-PROG "CXX" c++ "$@"; }
>
> # @FUNCTION: test-flag-F77
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the Fortran 77 compiler, else
> returns shell false.
> -test-flag-F77() { test-flag-PROG "F77" f77 "$@"; }
> +test-flag-F77() { _test-flag-PROG "F77" f77 "$@"; }
>
> # @FUNCTION: test-flag-FC
> # @USAGE:
> # @DESCRIPTION:
> # Returns shell true if is supported by the Fortran 90 compiler, else
> returns shell false.
> -test-flag-FC() { test-flag-PROG "FC" f95 "$@"; }
> +test-flag-FC() { _test-flag-PROG "FC" f95 "$@"; }
>
> #
[gentoo-dev] Last-rites: media-gfx/gqview
# Sergei Trofimovich (2020-02-08) # Abandoned upstream. Was never ported from gtk-2. # A possible alternative is media-gfx/geeqie (gqview fork). # Removal in 3 months. Bug #769440. media-gfx/gqview -- Sergei
Re: [gentoo-dev] [PATCH] multilib.eclass: Include /$(get_libdir) in PKG_CONFIG_SYSTEM_LIBRARY_PATH.
On Mon, 23 Nov 2020 21:55:35 -0500
Mike Gilbert wrote:
> From: Arfrever Frehtes Taifersar Arahesis
>
> Set also PKG_CONFIG_SYSTEM_INCLUDE_PATH for consistency.
>
> Bug: https://bugs.gentoo.org/756238
> Signed-off-by: Arfrever Frehtes Taifersar Arahesis
> ---
> eclass/multilib.eclass | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 9c7042fcd29..33ca9726131 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -498,6 +498,7 @@ multilib_toolchain_setup() {
> STRIP
> PKG_CONFIG_LIBDIR
> PKG_CONFIG_PATH
> + PKG_CONFIG_SYSTEM_INCLUDE_PATH
> PKG_CONFIG_SYSTEM_LIBRARY_PATH
> )
>
> @@ -547,7 +548,8 @@ multilib_toolchain_setup() {
> export CHOST=$(get_abi_CHOST $1)
> export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
> export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
> - export
> PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/usr/$(get_libdir)
> + export PKG_CONFIG_SYSTEM_INCLUDE_PATH=${EPREFIX}/usr/include
> + export
> PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/$(get_libdir):${EPREFIX}/usr/$(get_libdir)
> fi
> }
The patch looks good. Feel free to push.
--
Sergei
Re: [gentoo-dev] Incoming >=sys-libs/timezone-data-2020d[zic-slim] breakage
On Thu, 29 Oct 2020 19:10:00 +0100 Toralf Förster wrote: > On 10/29/20 10:14 AM, Sergei Trofimovich wrote: > >You can enable new default explicitly with USE=zic-slim switch. > > will do it here at the tinderbox Thank you! That will be very useful! -- Sergei
[gentoo-dev] Incoming >=sys-libs/timezone-data-2020d[zic-slim] breakage
Tl;DR: Upstream timezone-data-2020b changed the way /usr/share/zoneinfo files are generated by default. Gentoo does NOT enable this new default to keep existing software running (so far). You can enable new default explicitly with USE=zic-slim switch. Libraries and tools that parse /usr/share/zoneinfo will break in trivial (crashes) or very obscure ways (DST time switch will not happen and will report wrong time). What can you do: If you are feeling brave then enable USE=zic-slim to identify and fix affected packages. Sometimes bugs are specific to a timezone you are in. Running a testsuite is probably the best way to find problems. If you found a bug check that USE=-zic-slim makes it go away and report (and/or fix) it upstream and add it to the gentoo's tracker bug: https://bugs.gentoo.org/749591. What actually changed: From https://data.iana.org/time-zones/tzdb/NEWS: ``` Release 2020b - 2020-10-06 18:35:04 -0700 ... zic now defaults to '-b slim' instead of to '-b fat'. ``` Mechanically both 'fat' and 'slim' are the same VER=2 (or 3 for some timezones) file format from 'man 5 tzfile'. But 'fat'/'slim' contents is different. From 'man 8 zic': ``` -b bloat If bloat is fat, generate additional data entries that work around potential bugs or incompatibilities in older software, such as software that mishandles the 64-bit generated data. If bloat is slim, keep the output files small; this can help check for the bugs and incompatibilities. Although the default is currently fat, this is intended to change in future zic versions, as software that mishandles the 64-bit data typically mishandles timestamps after the year 2038 anyway. ``` Thus ideally libraries should already handle both flavours. But due to bugs some libraries will break. File format spec is an RFC8536: https://www.rfc-editor.org/rfc/rfc8536.txt Good luck! -- Sergei
Re: [gentoo-dev] Trying to use Python3.9 as default for my laptop
On Thu, 15 Oct 2020 00:01:58 +0300 Alexey 'Alexxy' Shvetsov wrote: ... > sys-devel/gdb > > So i wanna ask maintainers of this packages add python3_9 to pytargets (they > builds and works fine for me) or if they dont mind give me a right to do so =) Sure. Go ahead. -- Sergei
Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280
On Fri, 28 Aug 2020 10:10:02 +0200 Fabian Groffen wrote: > On 28-08-2020 08:52:09 +0100, Sergei Trofimovich wrote: > > On Fri, 28 Aug 2020 07:37:54 +0100 > > Sergei Trofimovich wrote: > > > > > On Fri, 28 Aug 2020 08:15:47 +0200 > > > Jaco Kroon wrote: > > > > > > > Hi All, > > > > > > > > https://bugs.gentoo.org/731280 > > > > > > > > Summary: > > > > > > > > This machine uses a clang/LLVM toolchain. > > > > Asterisk fails to compile, ./configure fails with: > > > > > > > > checking for RAII support... checking for clang -fblocks... > > > > configure: error: BlocksRuntime is required for clang, please install > > > > libblocksruntime > > > > > > > > I suspect this explains the issue: > > > > > > > > https://github.com/mackyle/blocksruntime > > > > > > > > I have no idea how to actually solve this. > > > > > > honggfuzz also needs it as it happens to use -fblocks on clang: > > > https://bugs.gentoo.org/729256 > > > > > > We need to package the library. I can give it a try. > > > > Packaged library as sys-libs/blocksruntime: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae376c73ef197d6c7aa619e821c436ccab0cd77e > > > > Usage example for app-forensics/honggfuzz: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd841336dfdefbc14907e2d9b1eb1a1a3f5f8b8e > > > > This is cool, but shouldn't it be something like openmp? (e.g. blocks) You mean when -fopenmp is present in LDFLAGS compiler itself pulls in runtime? That would be ideal. But currently clang does not install blocks runtime. > There is no reason blocks have to be used if not on macOS (where system > headers use blocks features). Sure. As with most extensions it can be avoided. Alas some projects use it is for convenience. At least honggfuzz uses blocks with __attribute__(cleanup) to emulate lexical scope destructors: https://github.com/google/honggfuzz/blob/03bbc2de983f13cfcd880f72e3a56582c4f82f24/libhfcommon/util.h#L57 -- Sergei
Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280
On Fri, 28 Aug 2020 07:37:54 +0100 Sergei Trofimovich wrote: > On Fri, 28 Aug 2020 08:15:47 +0200 > Jaco Kroon wrote: > > > Hi All, > > > > https://bugs.gentoo.org/731280 > > > > Summary: > > > > This machine uses a clang/LLVM toolchain. > > Asterisk fails to compile, ./configure fails with: > > > > checking for RAII support... checking for clang -fblocks... > > configure: error: BlocksRuntime is required for clang, please install > > libblocksruntime > > > > I suspect this explains the issue: > > > > https://github.com/mackyle/blocksruntime > > > > I have no idea how to actually solve this. > > honggfuzz also needs it as it happens to use -fblocks on clang: > https://bugs.gentoo.org/729256 > > We need to package the library. I can give it a try. Packaged library as sys-libs/blocksruntime: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae376c73ef197d6c7aa619e821c436ccab0cd77e Usage example for app-forensics/honggfuzz: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd841336dfdefbc14907e2d9b1eb1a1a3f5f8b8e -- Sergei
Re: [gentoo-dev] net-misc/asterisk fails to compile: clang/LLVM: bug 731280
On Fri, 28 Aug 2020 08:15:47 +0200 Jaco Kroon wrote: > Hi All, > > https://bugs.gentoo.org/731280 > > Summary: > > This machine uses a clang/LLVM toolchain. > Asterisk fails to compile, ./configure fails with: > > checking for RAII support... checking for clang -fblocks... > configure: error: BlocksRuntime is required for clang, please install > libblocksruntime > > I suspect this explains the issue: > > https://github.com/mackyle/blocksruntime > > I have no idea how to actually solve this. honggfuzz also needs it as it happens to use -fblocks on clang: https://bugs.gentoo.org/729256 We need to package the library. I can give it a try. -- Sergei
Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions
On Fri, 07 Aug 2020 21:45:48 +0200 Michał Górny wrote: > But I suppose being sarcastic is the new norm and should be documented as > such. I am not sarcastic if it was your implication. -- Sergei
Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions
On Fri, 7 Aug 2020 14:25:04 -0400
Michael Orlitzky wrote:
> When you ignore the devmanual and the pkgcheck warning and the 10+
> threads I've started about the issue, and make changes like...
>
> --- a/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
> +++ b/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
># Distributed under the terms of the GNU General Public License v2
>
>EAPI=6
> @@ -21,8 +21,7 @@ RDEPEND="${RDEPEND}
> x11-apps/bitmap
> x11-apps/iceauth
> x11-apps/luit
> - x11-apps/mkfontdir
> - x11-apps/mkfontscale
> + >=x11-apps/mkfontscale-1.2.0
> x11-apps/sessreg
>
>
> This is what portage does:
>
> $ sudo emerge -uDN @world
> Password:
> Calculating dependencies... done!
>
> emerge: there are no ebuilds to satisfy "x11-apps/mkfontdir".
> (dependency required by "x11-base/xorg-x11-7.4-r3::gentoo"
> [installed])
> (dependency required by "@selected" [set])
> (dependency required by "@world" [argument])
After PAM virtual removal and a bunch of similar large-scale
changes done by QA members I assume it's a new norm and
should be documented as such.
I ended up enabling --changed-deps by default on my systems
to make them upgradeable.
--
Sergei
Re: [gentoo-dev] [PATCH 2/4] dev-haskell/cryptonite: Change USE to cpu_flags_x86_rdrand
On Mon, 13 Jul 2020 19:11:52 +0200
"Francisco Blas Izquierdo Riera (klondike)" wrote:
> Package-Manager: Portage-2.3.99, Repoman-2.3.23
> Signed-off-by: Francisco Blas Izquierdo Riera (klondike)
> ---
> dev-haskell/cryptonite/cryptonite-0.21.ebuild | 4 ++--
> dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild | 2 +-
> dev-haskell/cryptonite/metadata.xml | 1 -
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> index 531dfe8cfb7..c3497dae415 100644
> --- a/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> +++ b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2019 Gentoo Authors
> +# Copyright 1999-2020 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> EAPI=7
> @@ -16,7 +16,7 @@
> SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
> LICENSE="BSD"
> SLOT="0/${PV}"
> KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux"
> -IUSE="cpu-flags-x86-rdrand cpu_flags_x86_aes cpu_flags_x86_sse2
> cpu_flags_x86_sse4_1 +integer-gmp"
> +IUSE="cpu_flags_x86_rdrand cpu_flags_x86_aes cpu_flags_x86_sse2
> cpu_flags_x86_sse4_1 +integer-gmp"
>
> RDEPEND=">=dev-haskell/memory-0.8:=[profile?]
> >=dev-lang/ghc-7.4.1:=
> diff --git a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> index 8d097bb5cfa..3cdbcf44b91 100644
> --- a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> +++ b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
> @@ -16,7 +16,7 @@
> SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
> LICENSE="BSD"
> SLOT="0/${PV}"
> KEYWORDS="~amd64 ~x86"
> -IUSE="+cpu-flags-x86-rdrand +cpu_flags_x86_aes cpu_flags_x86_sse
> cpu_flags_x86_sse4_1 +integer-gmp"
> +IUSE="+cpu_flags_x86_rdrand +cpu_flags_x86_aes cpu_flags_x86_sse
> cpu_flags_x86_sse4_1 +integer-gmp"
>
> RDEPEND=">=dev-haskell/basement-0.0.6:=[profile?]
> >=dev-haskell/memory-0.14.18:=[profile?]
> diff --git a/dev-haskell/cryptonite/metadata.xml
> b/dev-haskell/cryptonite/metadata.xml
> index c845b334ecd..8e02ebe625c 100644
> --- a/dev-haskell/cryptonite/metadata.xml
> +++ b/dev-haskell/cryptonite/metadata.xml
> @@ -29,7 +29,6 @@
> Evaluate the security related to your requirements before using.
>
>
> - allow compilation with RDRAND on
> system and architecture that supports it
> Whether or not to use GMP for some
> functions
>
>
> --
> 2.26.2
>
Looks good!
--
Sergei
[gentoo-dev] dev-libs/cloog is up for grabs
dev-libs/cloog used to be maintaned by toolchain@. It's not used by nowadays' gcc and thus dropped to maintainer-needed. Two open bugs: - https://bugs.gentoo.org/595132 - https://bugs.gentoo.org/650304 Feel free to grab! -- Sergei
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 13:41:13 -0400 Aaron Bauman wrote: > On June 26, 2020 12:47:24 PM EDT, Sergei Trofimovich > wrote: > >On Fri, 26 Jun 2020 11:38:58 +0200 > >Michał Górny wrote: > > > >> On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > >> > On Fri, 26 Jun 2020 07:29:45 + > >> > Michał Górny wrote: > >> > > >> > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > napisał(a): > >> > > > On Sat, 20 Jun 2020 16:29:53 +0100 > >> > > > Sergei Trofimovich wrote: > >> > > > > >> > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > >> > > > > Michał Górny wrote: > >> > > > > > >> > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich > >wrote: > >> > > > > > > Give maintainers the chance to act and flag packages that > >pull in > >> > > > python:2.7. > >> > > > > > > Signed-off-by: Sergei Trofimovich > >> > > > > > > --- > >> > > > > > > profiles/package.deprecated | 4 > >> > > > > > > 1 file changed, 4 insertions(+) > >> > > > > > > > >> > > > > > > diff --git a/profiles/package.deprecated > >> > > > b/profiles/package.deprecated > >> > > > > > > index a756e845f47..bb661571962 100644 > >> > > > > > > --- a/profiles/package.deprecated > >> > > > > > > +++ b/profiles/package.deprecated > >> > > > > > > @@ -17,6 +17,10 @@ > >> > > > > > > > >> > > > > > > #--- END OF EXAMPLES --- > >> > > > > > > > >> > > > > > > +# Sergei Trofimovich (2020-06-20) > >> > > > > > > +# Deprecated. Consider poring to python 3 and drop > >support for > >> > > > python2. > >> > > > > > > +dev-lang/python:2.7 > >> > > > > > > + > >> > > > > > > # Sergei Trofimovich (2020-02-22) > >> > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > >provider. > >> > > > > > > # Use that instead. Or even better use none of them. > >It's a > >> > > > > > > >> > > > > > >> > > > > > It will trigger the same for packages that support *only* > >> > > > > > Python 2.7, as well as these that support 2.7 in addition > >to 3 > >> > > > because > >> > > > > > they have 2.7 deps. > >> > > > > > >> > > > > If we expect actions by developers on both cases I don't see > >a > >> > > > problem with that. > >> > > > > >> > > > Pushed as: > >> > > > > >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > >> > > > with full text being: > >> > > > > >> > > > +# Sergei Trofimovich (2020-06-26) > >> > > > +# Deprecated. > >> > > > +# - optional python:2.7 dependency should be dropped if no > >reverse > >> > > > +# dependencies are using it. > >> > > > +# - mandatory python:2.7 depepndency will require package > >porting > >> > > > +# or package removal if no reverse dependencies are using > >it. > >> > > > +dev-lang/python:2.7 > >> > > > >> > > You've just introduced 829 CI warnings > >> > > >> > That's the intention. > >> > > >> > > effectively disabling the ability to distinguish *new* problems > >in these packages. > >> > > >> > Correct. Citing above: > >> > > >> > "If we expect actions by developers on both cases I don't see a > >problem with that." > >> > > >> > I assume we still do. > >> > >> Not exactly. You've pinpointed the wrong target. > >> > >> First of all, we want people to support Python 3. Removing support > >for
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 19:17:50 +0200 Michał Górny wrote: > On Fri, 2020-06-26 at 17:47 +0100, Sergei Trofimovich wrote: > > On Fri, 26 Jun 2020 11:38:58 +0200 > > Michał Górny wrote: > > > > > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > > > On Fri, 26 Jun 2020 07:29:45 + > > > > Michał Górny wrote: > > > > > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > > > napisał(a): > > > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > > > Sergei Trofimovich wrote: > > > > > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > > > Michał Górny wrote: > > > > > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > > > > > > > > > > > > Give maintainers the chance to act and flag packages that > > > > > > > > > pull in > > > > > > python:2.7. > > > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > > > --- > > > > > > > > > profiles/package.deprecated | 4 > > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > > > b/profiles/package.deprecated > > > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > > > --- a/profiles/package.deprecated > > > > > > > > > +++ b/profiles/package.deprecated > > > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > > > +# Deprecated. Consider poring to python 3 and drop support > > > > > > > > > for > > > > > > python2. > > > > > > > > > +dev-lang/python:2.7 > > > > > > > > > + > > > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 > > > > > > > > > provider. > > > > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > > > > > > > > > > > > because > > > > > > > > they have 2.7 deps. > > > > > > > > > > > > > > If we expect actions by developers on both cases I don't see a > > > > > > > > > > > > > problem with that. > > > > > > > > > > > > Pushed as: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > > > with full text being: > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > > > +# Deprecated. > > > > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > > > > +# dependencies are using it. > > > > > > +# - mandatory python:2.7 depepndency will require package porting > > > > > > +# or package removal if no reverse dependencies are using it. > > > > > > +dev-lang/python:2.7 > > > > > > > > > > You've just introduced 829 CI warnings > > > > > > > > That's the intention. > > > > > > > > > effectively disabling the ability to distinguish *new* problems in > > > > > these packages. > > > > > > > > Correct. Citing above: > > > > > > > > "If we expect actions by developers on both cases I don't see a > > > > problem with that.&q
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 11:38:58 +0200 Michał Górny wrote: > On Fri, 2020-06-26 at 09:51 +0100, Sergei Trofimovich wrote: > > On Fri, 26 Jun 2020 07:29:45 + > > Michał Górny wrote: > > > > > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > > > napisał(a): > > > > On Sat, 20 Jun 2020 16:29:53 +0100 > > > > Sergei Trofimovich wrote: > > > > > > > > > On Sat, 20 Jun 2020 16:05:38 +0200 > > > > > Michał Górny wrote: > > > > > > > > > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > > > > > Give maintainers the chance to act and flag packages that pull in > > > > > > > > > > > python:2.7. > > > > > > > Signed-off-by: Sergei Trofimovich > > > > > > > --- > > > > > > > profiles/package.deprecated | 4 > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > diff --git a/profiles/package.deprecated > > > > b/profiles/package.deprecated > > > > > > > index a756e845f47..bb661571962 100644 > > > > > > > --- a/profiles/package.deprecated > > > > > > > +++ b/profiles/package.deprecated > > > > > > > @@ -17,6 +17,10 @@ > > > > > > > > > > > > > > #--- END OF EXAMPLES --- > > > > > > > > > > > > > > +# Sergei Trofimovich (2020-06-20) > > > > > > > +# Deprecated. Consider poring to python 3 and drop support for > > > > > > > > > > > python2. > > > > > > > +dev-lang/python:2.7 > > > > > > > + > > > > > > > # Sergei Trofimovich (2020-02-22) > > > > > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > > > > > > > # Use that instead. Or even better use none of them. It's a > > > > > > > > > > > > > > > > > > > > > > > > It will trigger the same for packages that support *only* > > > > > > Python 2.7, as well as these that support 2.7 in addition to 3 > > > > because > > > > > > they have 2.7 deps. > > > > > > > > > > If we expect actions by developers on both cases I don't see a > > > > problem with that. > > > > > > > > Pushed as: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > > > > with full text being: > > > > > > > > +# Sergei Trofimovich (2020-06-26) > > > > +# Deprecated. > > > > +# - optional python:2.7 dependency should be dropped if no reverse > > > > +# dependencies are using it. > > > > +# - mandatory python:2.7 depepndency will require package porting > > > > +# or package removal if no reverse dependencies are using it. > > > > +dev-lang/python:2.7 > > > > > > You've just introduced 829 CI warnings > > > > That's the intention. > > > > > effectively disabling the ability to distinguish *new* problems in these > > > packages. > > > > Correct. Citing above: > > > > "If we expect actions by developers on both cases I don't see a problem > > with that." > > > > I assume we still do. > > Not exactly. You've pinpointed the wrong target. > > First of all, we want people to support Python 3. Removing support for > Python 2 is a secondary goal. What is the desired end state here? All packages that depend on python should support python3? > Flagging packages that support Python 2 in addition to Python 3 > and cause no trouble in py2 cleanup is doubtful. What is "py2 cleanup"? I still struggle to understand what packages require change and which do not. Is there one pager doc that explains a few things for me: - How packages are picked for masking? Maybe we can deprecate them instead? Or we (I) can write a bit of code that flags packages requiring maintainers' attention. - What is the expected end state for the "py2 cleanup"? The doc would also be a good link to add to recently added "# Py2 only" masks as well. > Flagging packages that support 2+3 because of their revdeps is not > helpful at all. It's just noise to the maintainer who can't remove py2 > because of revdeps. I agree it can be spammy if we expect to have many packages with python2 support for an extended period of time (3+ months). If it's seen by others as too noisy I can revert the commit now. > Flagging dev-python/pypy* which needs py2 but is entirely outside > the eclass system is not helpful at all. To pick a concrete example: from what I read above I don't see why app-misc/golly was masked for removal. -- Sergei
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Fri, 26 Jun 2020 07:29:45 + Michał Górny wrote: > Dnia June 26, 2020 6:42:57 AM UTC, Sergei Trofimovich > napisał(a): > >On Sat, 20 Jun 2020 16:29:53 +0100 > >Sergei Trofimovich wrote: > > > >> On Sat, 20 Jun 2020 16:05:38 +0200 > >> Michał Górny wrote: > >> > >> > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > >> > > Give maintainers the chance to act and flag packages that pull in > >python:2.7. > >> > > > >> > > Signed-off-by: Sergei Trofimovich > >> > > --- > >> > > profiles/package.deprecated | 4 > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/profiles/package.deprecated > >b/profiles/package.deprecated > >> > > index a756e845f47..bb661571962 100644 > >> > > --- a/profiles/package.deprecated > >> > > +++ b/profiles/package.deprecated > >> > > @@ -17,6 +17,10 @@ > >> > > > >> > > #--- END OF EXAMPLES --- > >> > > > >> > > +# Sergei Trofimovich (2020-06-20) > >> > > +# Deprecated. Consider poring to python 3 and drop support for > >python2. > >> > > +dev-lang/python:2.7 > >> > > + > >> > > # Sergei Trofimovich (2020-02-22) > >> > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > >> > > # Use that instead. Or even better use none of them. It's a > >> > > >> > >> > It will trigger the same for packages that support *only* > >> > Python 2.7, as well as these that support 2.7 in addition to 3 > >because > >> > they have 2.7 deps. > >> > >> If we expect actions by developers on both cases I don't see a > >problem with that. > > > >Pushed as: > >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 > >with full text being: > > > >+# Sergei Trofimovich (2020-06-26) > >+# Deprecated. > >+# - optional python:2.7 dependency should be dropped if no reverse > >+# dependencies are using it. > >+# - mandatory python:2.7 depepndency will require package porting > >+# or package removal if no reverse dependencies are using it. > >+dev-lang/python:2.7 > > You've just introduced 829 CI warnings That's the intention. > effectively disabling the ability to distinguish *new* problems in these > packages. Correct. Citing above: "If we expect actions by developers on both cases I don't see a problem with that." I assume we still do. -- Sergei
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Sat, 20 Jun 2020 16:29:53 +0100 Sergei Trofimovich wrote: > On Sat, 20 Jun 2020 16:05:38 +0200 > Michał Górny wrote: > > > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > > Give maintainers the chance to act and flag packages that pull in > > > python:2.7. > > > > > > Signed-off-by: Sergei Trofimovich > > > --- > > > profiles/package.deprecated | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/profiles/package.deprecated b/profiles/package.deprecated > > > index a756e845f47..bb661571962 100644 > > > --- a/profiles/package.deprecated > > > +++ b/profiles/package.deprecated > > > @@ -17,6 +17,10 @@ > > > > > > #--- END OF EXAMPLES --- > > > > > > +# Sergei Trofimovich (2020-06-20) > > > +# Deprecated. Consider poring to python 3 and drop support for python2. > > > +dev-lang/python:2.7 > > > + > > > # Sergei Trofimovich (2020-02-22) > > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > > > # Use that instead. Or even better use none of them. It's a > > > > > It will trigger the same for packages that support *only* > > Python 2.7, as well as these that support 2.7 in addition to 3 because > > they have 2.7 deps. > > If we expect actions by developers on both cases I don't see a problem with > that. Pushed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79d65d6641cfc0ef7b44df491c390e8c880e3049 with full text being: +# Sergei Trofimovich (2020-06-26) +# Deprecated. +# - optional python:2.7 dependency should be dropped if no reverse +# dependencies are using it. +# - mandatory python:2.7 depepndency will require package porting +# or package removal if no reverse dependencies are using it. +dev-lang/python:2.7 -- Sergei
Re: [gentoo-dev] [PATCH] unpacker.eclass: call BUILD_AR when unpacking deb files
On Mon, 22 Jun 2020 11:10:55 -0400
Mike Gilbert wrote:
> Closes: https://bugs.gentoo.org/722054
> Signed-off-by: Mike Gilbert
> ---
> eclass/unpacker.eclass | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> index 865e2e1a1a58..63aedee4480e 100644
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -17,6 +17,8 @@
> if [[ -z ${_UNPACKER_ECLASS} ]]; then
> _UNPACKER_ECLASS=1
>
> +inherit toolchain-funcs
> +
> # @ECLASS-VARIABLE: UNPACKER_BZ2
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> @@ -279,8 +281,7 @@ unpack_deb() {
> done
> } < "${deb}"
> else
> - local AR=${AR-ar}
> - ${AR} x "${deb}" || die
> + $(tc-getBUILD_AR) x "${deb}" || die
> fi
>
> unpacker ./data.tar*
> --
> 2.27.0
Looks good!
--
Sergei
Re: [gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
On Sat, 20 Jun 2020 16:05:38 +0200 Michał Górny wrote: > On Sat, 2020-06-20 at 14:57 +0100, Sergei Trofimovich wrote: > > Give maintainers the chance to act and flag packages that pull in > > python:2.7. > > > > Signed-off-by: Sergei Trofimovich > > --- > > profiles/package.deprecated | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/profiles/package.deprecated b/profiles/package.deprecated > > index a756e845f47..bb661571962 100644 > > --- a/profiles/package.deprecated > > +++ b/profiles/package.deprecated > > @@ -17,6 +17,10 @@ > > > > #--- END OF EXAMPLES --- > > > > +# Sergei Trofimovich (2020-06-20) > > +# Deprecated. Consider poring to python 3 and drop support for python2. > > +dev-lang/python:2.7 > > + > > # Sergei Trofimovich (2020-02-22) > > # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. > > # Use that instead. Or even better use none of them. It's a > > It will trigger the same for packages that support *only* > Python 2.7, as well as these that support 2.7 in addition to 3 because > they have 2.7 deps. If we expect actions by developers on both cases I don't see a problem with that. -- Sergei pgp9G4XWt3F8Y.pgp Description: Цифровая подпись OpenPGP
[gentoo-dev] [PATCH] profiles/package.deprecated: deprecate python:2.7
Give maintainers the chance to act and flag packages that pull in python:2.7. Signed-off-by: Sergei Trofimovich --- profiles/package.deprecated | 4 1 file changed, 4 insertions(+) diff --git a/profiles/package.deprecated b/profiles/package.deprecated index a756e845f47..bb661571962 100644 --- a/profiles/package.deprecated +++ b/profiles/package.deprecated @@ -17,6 +17,10 @@ #--- END OF EXAMPLES --- +# Sergei Trofimovich (2020-06-20) +# Deprecated. Consider poring to python 3 and drop support for python2. +dev-lang/python:2.7 + # Sergei Trofimovich (2020-02-22) # virtual/libstdc++ has only one sys-libs/libstdc++-v3 provider. # Use that instead. Or even better use none of them. It's a -- 2.27.0
[gentoo-dev] Re: [gentoo-dev-announce] */*: Mask Py2 only packages
On Sat, 20 Jun 2020 00:43:03 -0400 Aaron Bauman wrote: > # Aaron Bauman (2020-06-20) > # Py2 only > # Removal in 14 days ... > app-misc/golly If you decided to delete a maintained package you should file a bug against the maintainer. Otherwise they won't see the effect until mask hits the users. -- Sergei
[gentoo-dev] Re: [PATCH 2/2] multilib.eclass: drop amd64 from maintainers
On Sun, 14 Jun 2020 11:57:06 -0400 Mike Gilbert wrote: > Acked-by: Agostino Sarubbo > Signed-off-by: Mike Gilbert > --- > eclass/multilib.eclass | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass > index 29d44768adec..4d1be867f14d 100644 > --- a/eclass/multilib.eclass > +++ b/eclass/multilib.eclass > @@ -3,7 +3,6 @@ > > # @ECLASS: multilib.eclass > # @MAINTAINER: > -# am...@gentoo.org > # toolch...@gentoo.org > # @BLURB: This eclass is for all functions pertaining to handling multilib > configurations. > # @DESCRIPTION: > -- > 2.27.0 > Looks good! -- Sergei
[gentoo-dev] Re: [PATCH 1/2] multilib.eclass: use tc-export to simplify multilib_toolchain_setup
On Sun, 14 Jun 2020 11:57:05 -0400
Mike Gilbert wrote:
> This also gives a tiny performance boost by reducing the number of
> subshells that are forked.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/multilib.eclass | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 342d21a2e1c3..29d44768adec 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -506,19 +506,15 @@ multilib_toolchain_setup() {
> # Make sure ${save_restore_variables[@]} list matches below.
> export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
>
> - export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
> + # Append ABI flags to CHOST-prefixed tools
> export CC="$(tc-getCC) $(get_abi_CFLAGS)"
> export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
> export F77="$(tc-getF77) $(get_abi_CFLAGS)"
> export FC="$(tc-getFC) $(get_abi_CFLAGS)"
> export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
> - export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
> - export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use
> '${CHOST}-objdump'
> - export PKG_CONFIG="$(tc-getPKG_CONFIG)"
> - export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use
> '${CHOST}-ranlib'
> - export READELF="$(tc-getREADELF)" # Avoid 'readelf', use
> '${CHOST}-readelf'
> - export STRINGS="$(tc-getSTRINGS)" # Avoid 'strings', use
> '${CHOST}-strings'
> - export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use
> '${CHOST}-strip'
> +
> + # Use CHOST-prefixed tools
> + tc-export AR NM OBJDUMP PKG_CONFIG RANLIB READELF STRINGS STRIP
>
> export CHOST=$(get_abi_CHOST $1)
> export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
> --
> 2.27.0
>
--
Sergei
[gentoo-dev] [PATCH 2/2] multilib.eclass: populate STRINGS
For both multilib and non-multilib profiles binutils provides
tools with native CHOST prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-strings' and 'strings'.
autoconf usually uses AC_CHECK_TOOL(STRINGS, strings) autodetection
to discover either of these.
The change overrides STRINGS and friends to 'x86_64-pc-linux-gnu-strings'
for multilib setup similar to other environment variables.
Tested on media-libs/x264 and x11-libs/cairo packages.
Signed-off-by: Sergei Trofimovich
---
eclass/multilib.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 54ff1509ead..342d21a2e1c 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -470,6 +470,7 @@ multilib_toolchain_setup() {
PKG_CONFIG
RANLIB
READELF
+ STRINGS
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
@@ -504,6 +505,7 @@ multilib_toolchain_setup() {
#
# Make sure ${save_restore_variables[@]} list matches below.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
+
export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
@@ -515,7 +517,9 @@ multilib_toolchain_setup() {
export PKG_CONFIG="$(tc-getPKG_CONFIG)"
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use
'${CHOST}-ranlib'
export READELF="$(tc-getREADELF)" # Avoid 'readelf', use
'${CHOST}-readelf'
+ export STRINGS="$(tc-getSTRINGS)" # Avoid 'strings', use
'${CHOST}-strings'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use
'${CHOST}-strip'
+
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
--
2.27.0
[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*STRINGS helpers
Signed-off-by: Sergei Trofimovich
---
eclass/toolchain-funcs.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index a88d9a114ff..ec7b920bcfa 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -73,6 +73,10 @@ tc-getCXX() { tc-getPROG CXX g++ "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the linker
tc-getLD() { tc-getPROG LD ld "$@"; }
+# @FUNCTION: tc-getSTRINGS
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the strings program
+tc-getSTRINGS() { tc-getPROG STRINGS strings "$@"; }
# @FUNCTION: tc-getSTRIP
# @USAGE: [toolchain prefix]
# @RETURN: name of the strip program
@@ -150,6 +154,10 @@ tc-getBUILD_CXX() { tc-getBUILD_PROG CXX g++ "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the linker for building binaries to run on the build machine
tc-getBUILD_LD() { tc-getBUILD_PROG LD ld "$@"; }
+# @FUNCTION: tc-getBUILD_STRINGS
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the strings program for building binaries to run on the
build machine
+tc-getBUILD_STRINGS() { tc-getBUILD_PROG STRINGS strings "$@"; }
# @FUNCTION: tc-getBUILD_STRIP
# @USAGE: [toolchain prefix]
# @RETURN: name of the strip program for building binaries to run on the build
machine
--
2.27.0
[gentoo-dev] Re: [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one
On Fri, 12 Jun 2020 17:43:10 -0400
Mike Gilbert wrote:
> On Fri, Jun 12, 2020 at 5:25 PM Sergei Trofimovich wrote:
> >
> > x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
> > tool on sys-devel/binutils-config[-native-symlinks] system as:
> > `meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
> >
> > It's caused by the code that locates the tool as:
> > `prog_nm = find_program('nm')`.
> >
> > The change adds 'nm' tool along with other binutils tools.
> >
> > CC: William Hubbs
> > CC: Mike Gilbert
> > Closes: https://bugs.gentoo.org/720886
> > Signed-off-by: Sergei Trofimovich
> > ---
> > eclass/meson.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index e79faa1beea..1590c1f14cf 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -178,6 +178,7 @@ _meson_create_cross_file() {
> > cpp = $(_meson_env_array "$(tc-getCXX)")
> > fortran = $(_meson_env_array "$(tc-getFC)")
> > llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
> > + nm = $(_meson_env_array "$(tc-getNM)")
> > objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
> > pkgconfig = '$(tc-getPKG_CONFIG)'
> > @@ -228,6 +229,7 @@ _meson_create_native_file() {
> > cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
> > fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
> > llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
> > + nm = $(_meson_env_array "$(tc-getBUILD_NM)")
> > objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
> > objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
> > pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
> > --
> > 2.27.0
> >
>
> Looks good.
Thank you! Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da03d40f146a646c38e75fd0a6fc299b5aeba505
--
Sergei
[gentoo-dev] [PATCH v2] meson.eclass: override 'nm' tool with tuple-prefixed one
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.
The change adds 'nm' tool along with other binutils tools.
CC: William Hubbs
CC: Mike Gilbert
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich
---
eclass/meson.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..1590c1f14cf 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getNM)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getBUILD_NM)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
--
2.27.0
[gentoo-dev] [PATCH] meson.eclass: override 'nm' tool with tuple-prefixed one
x11-libs/libdrm and media-libs/libglvnd fail to find 'nm'
tool on sys-devel/binutils-config[-native-symlinks] system as:
`meson.build:40:0: ERROR: Program(s) ['nm'] not found or not executable`
It's caused by the code that locates the tool as:
`prog_nm = find_program('nm')`.
The change adds 'nm' tool along with other binutils tools.
CC: William Hubbs
CC: Mike Gilbert
Closes: https://bugs.gentoo.org/720886
Signed-off-by: Sergei Trofimovich
---
eclass/meson.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index e79faa1beea..20f74a29b83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -178,6 +178,7 @@ _meson_create_cross_file() {
cpp = $(_meson_env_array "$(tc-getCXX)")
fortran = $(_meson_env_array "$(tc-getFC)")
llvm-config = '$(tc-getPROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getNM nm)")
objc = $(_meson_env_array "$(tc-getPROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getPROG OBJCXX c++)")
pkgconfig = '$(tc-getPKG_CONFIG)'
@@ -228,6 +229,7 @@ _meson_create_native_file() {
cpp = $(_meson_env_array "$(tc-getBUILD_CXX)")
fortran = $(_meson_env_array "$(tc-getBUILD_PROG FC gfortran)")
llvm-config = '$(tc-getBUILD_PROG LLVM_CONFIG llvm-config)'
+ nm = $(_meson_env_array "$(tc-getBUILD_NM nm)")
objc = $(_meson_env_array "$(tc-getBUILD_PROG OBJC cc)")
objcpp = $(_meson_env_array "$(tc-getBUILD_PROG OBJCXX c++)")
pkgconfig = '$(tc-getBUILD_PKG_CONFIG)'
--
2.27.0
Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice
On Mon, 8 Jun 2020 03:02:49 -0700 Georgy Yakovlev wrote: > opened a PR to add it to repoman: > > https://github.com/gentoo/portage/pull/554 Thank you! -- Sergei
Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice
On Mon, 08 Jun 2020 10:13:24 +0200 Andreas Sturmlechner wrote: > This eclass no longer receives any changes. > Everyone must port to cmake.eclass. We have quite a few ebuilds that still use it: $ git grep -E 'inherit.*cmake-utils' | wc -l 1338 I don't see any warnings reported by repoman to suggest users to migrate away. Should we have one? -- Sergei
Re: [gentoo-dev] [PATCH 0/2] multilib.eclass: improve multilib handling of pkg-config
On Sat, 6 Jun 2020 15:24:03 -0400 Mike Gilbert wrote: > These patches are part of a larger change to eliminate MULTILIB_USEDEP > from virtual/pkgconfig dependencies in BDEPEND. > > See https://bugs.gentoo.org/723112 and > https://github.com/gentoo/gentoo/pull/16025. > > Mike Gilbert (2): > multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in > multilib_toolchain_setup > multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup > > eclass/multilib.eclass | 4 > 1 file changed, 4 insertions(+) > Looks good! -- Sergei
Re: [gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878
On Sat, 30 May 2020 09:59:16 -0700
Manoj Gupta wrote:
> Also see https://bugs.chromium.org/p/chromium/issues/detail?id=1088210 on
> Chrome OS.
>
> Verified that this fixes the linux-headers build issue when gcc links are
> not installed.
>
> Thanks,
> Manoj
>
> On Sat, May 30, 2020 at 5:24 AM Sergei Trofimovich
> wrote:
>
> > Before the change HOSTCC always used gcc. This was
> > detected by Agostino on linux-headers package.
> >
> > After the change HOSTCC uses user-specified CC
> > (or BUILD_CC). Tested on native linux-headers
> > and on cross-*/linux-headers.
> >
> > CC: ker...@gentoo.org
> > Reported-by: Agostino Sarubbo
> > https://bugs.gentoo.org/725878
> > Signed-off-by: Sergei Trofimovich
> > ---
> > eclass/kernel-2.eclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 930bcf22e29..04edee33930 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -712,6 +712,7 @@ env_setup_xmakeopts() {
> > elif type -p ${CHOST}-ar > /dev/null ; then
> > xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> > fi
> > + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
> > export xmakeopts
> > }
> >
> > --
> > 2.26.2
Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3dd41142d73f41e2528eefa32e760fc3083001ee
--
Sergei
[gentoo-dev] [PATCH] kernel-2.eclass: use $(CC) as HOSTCC, bug #725878
Before the change HOSTCC always used gcc. This was
detected by Agostino on linux-headers package.
After the change HOSTCC uses user-specified CC
(or BUILD_CC). Tested on native linux-headers
and on cross-*/linux-headers.
CC: ker...@gentoo.org
Reported-by: Agostino Sarubbo
https://bugs.gentoo.org/725878
Signed-off-by: Sergei Trofimovich
---
eclass/kernel-2.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 930bcf22e29..04edee33930 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -712,6 +712,7 @@ env_setup_xmakeopts() {
elif type -p ${CHOST}-ar > /dev/null ; then
xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
fi
+ xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
export xmakeopts
}
--
2.26.2
Re: [gentoo-dev] Add more toolchain variables to emerge --info
On Thu, 28 May 2020 14:23:46 +0200 Agostino Sarubbo wrote: > https://bugs.gentoo.org/show_bug.cgi?id=722456 > > What is your opinion? Adding more build-related variables sounds great. -- Sergei
[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"
> >> > > > > >> + ;;
> >> > > > > >>
[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] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304
On Mon, 25 May 2020 11:30:29 -0400 Mike Gilbert wrote: > On Mon, May 25, 2020 at 9:06 AM Sergei Trofimovich wrote: > > > > Bug: https://bugs.gentoo.org/725304 > > Signed-off-by: Sergei Trofimovich > > Both patches look good to me. > > However, I think you should remove the bug number from the summary > line; it makes the summary too long and the Bug tag later in the > commit message is sufficient. Sounds good! Dropped bug number and pushed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ccdea417c4a259a03a745e3a977ac56827be5ae4 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7bd13f6d55a51f2a1f4da69a41df7973fa7503cc -- Sergei
[gentoo-dev] [PATCH 2/2] multilib.eclass: populate READELF, bug #725304
For both multilib and non-multilib profiles binutils provides
tools with native CHOST prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-readelf' and 'readelf'.
meson build system uses 'readelf' or $READELF binaries
and relies on meson.eclass to populate READELF.
The change overrides READELF and friends to 'x86_64-pc-linux-gnu-readelf'
for multilib setup similar to other environment variables.
Tested on net-libs/gssdp package.
Closes: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich
---
eclass/multilib.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index b79718bb193..ed54568aa2d 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -468,6 +468,7 @@ multilib_toolchain_setup() {
NM
OBJDUMP
RANLIB
+ READELF
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
@@ -510,6 +511,7 @@ multilib_toolchain_setup() {
export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use
'${CHOST}-objdump'
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use
'${CHOST}-ranlib'
+ export READELF="$(tc-getREADELF)" # Avoid 'readelf', use
'${CHOST}-readelf'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use
'${CHOST}-strip'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
--
2.26.2
[gentoo-dev] [PATCH 1/2] toolchain-funcs.eclass: export tc-get*READELF helpers, bug #725304
Bug: https://bugs.gentoo.org/725304
Signed-off-by: Sergei Trofimovich
---
eclass/toolchain-funcs.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 1bc6cbbc108..709c3baca53 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -85,6 +85,10 @@ tc-getNM() { tc-getPROG NM nm "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the archiver indexer
tc-getRANLIB() { tc-getPROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getREADELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector
+tc-getREADELF() { tc-getPROG READELF readelf "$@"; }
# @FUNCTION: tc-getOBJCOPY
# @USAGE: [toolchain prefix]
# @RETURN: name of the object copier
@@ -158,6 +162,10 @@ tc-getBUILD_NM() { tc-getBUILD_PROG NM nm "$@"; }
# @USAGE: [toolchain prefix]
# @RETURN: name of the archiver indexer for building binaries to run on the
build machine
tc-getBUILD_RANLIB() { tc-getBUILD_PROG RANLIB ranlib "$@"; }
+# @FUNCTION: tc-getBUILD_READELF
+# @USAGE: [toolchain prefix]
+# @RETURN: name of the ELF enspector for building binaries to run on the build
machine
+tc-getBUILD_READELF() { tc-getBUILD_PROG READELF readelf "$@"; }
# @FUNCTION: tc-getBUILD_OBJCOPY
# @USAGE: [toolchain prefix]
# @RETURN: name of the object copier for building binaries to run on the build
machine
@@ -376,6 +384,7 @@ tc-env_build() {
NM=$(tc-getBUILD_NM) \
PKG_CONFIG=$(tc-getBUILD_PKG_CONFIG) \
RANLIB=$(tc-getBUILD_RANLIB) \
+ READELF=$(tc-getBUILD_READELF) \
"$@"
}
--
2.26.2
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sun, 24 May 2020 09:40:50 +0800
"Pengcheng Xu" wrote:
> > USE=-native-symlinks removes a bunch of links that most packages use by
> > default
> > until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix it will
> > probably
> > disappear with USE=-native-symlinks.
> >
> > (At least eventually) 'emerge' should still be able to build most of
> > packages
> > in such environment. I expect initial breakage will be huge though.
> >
> > Using './configure && make && make install' style workflow will be more
> > tedious.
> > One workaround at least for gcc is to use something like:
> > $ PATH="$(gcc-config -B):$PATH"
> > It's not perfect. We'll see if toolchain can provide nicer environment.
> >
>
> Do we currently have (or is there a plan for) a mechanism to manage the
> symbolic links and/or create them after merging the package when necessary?
> It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
There currently is no nice way to get stable path with up-to-date
symlinks for current gcc/binutils. I think of adding a gentoo-specific
directory to manage symlinks similar to what 'gcc-config -B' provides
in a stable path that you can write once into user's PATH.
No concrete implementation yet. Filed https://bugs.gentoo.org/724980
to track it.
--
Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 22:41:02 -0400
Mike Gilbert wrote:
> On Fri, May 22, 2020 at 5:36 PM Sergei Trofimovich wrote:
> >
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> >
> > I added new USE=-native-symlinks mode for gcc-config and
> > binutils-config to ease detection of such packages.
> >
> > Native symlinks are still installed by default. Nothing should
> > break for users who use default USE flags.
> >
> > USE=-native-symlinks removes a bunch of links that most packages
> > use by default until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> > it will probably disappear with USE=-native-symlinks.
> >
> > (At least eventually) 'emerge' should still be able to build most
> > of packages in such environment. I expect initial breakage will be
> > huge though.
>
> Could you please add this flag to package.use.force?
Added as
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136
> I don't think we
> want to give people the impression that this is a well-supported
> configuration. I would only expect people to disable this if they want
> to break their system intentionally.
Yeah, today it's certainly a way to get your system in a miserable state.
My hope is that USE=-native-symlinks can get you a working Gentoo in a
near future by only fixing real package problems and limitations of their
build systems.
--
Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 23:40:22 -0700 Matt Turner wrote: > On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote: > > > > > > On 5/24/20 5:41 AM, Mike Gilbert wrote: > > > Also, people are likely to disable this accidentally via USE="-*". > > > > Counts as > > > > > if they want to break their system intentionally. > > Yes, but unfortunately catalyst's stage1 build does exactly this. > > Suggestions how to avoid doing this would be appreciated, but until > that's resolved we don't have carte blanche to break USE="-*". Ah, I keep forgetting about catalyst. Use-forced flags as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f8b5b847429642977d4c0497068a93222ff3136 While at it added a page that explains how to turn it back by enthusiasts: https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks and will collect more details on typical fixes and "this is fine to ignore" pitfalls. -- Sergei
Re: [gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248
On Sat, 23 May 2020 14:56:06 -0400
Mike wrote:
> On 5/22/20 2:57 PM, Sergei Trofimovich wrote:
> > Originally found in bug #705240 as:
> >
> > ```
> > error=0
> > ...
> > if [[ ${error} > 0 ]]; then
> > ...
> > ```
> >
> > '>' are string comparisons. They are benign in this case, but let's
> > be consistent and use integer comparison.
> >
> > CC: ker...@gentoo.org
> > Closes: https://bugs.gentoo.org/705248
> > Signed-off-by: Sergei Trofimovich
> > ---
> > eclass/linux-info.eclass | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> > index 44eebcf52a9..405ef5571e1 100644
> > --- a/eclass/linux-info.eclass
> > +++ b/eclass/linux-info.eclass
> > @@ -813,7 +813,7 @@ check_extra_config() {
> > linux_chkconfig_present ${config} || error=1
> > fi
> >
> > - if [[ ${error} > 0 ]]; then
> > + if [[ ${error} -gt 0 ]]; then
> > local report_func="eerror" local_error
> > local_error="ERROR_${config}"
> > local_error="${!local_error}"
> > @@ -848,14 +848,14 @@ check_extra_config() {
> > fi
> > done
> >
> > - if [[ ${hard_errors_count} > 0 ]]; then
> > + if [[ ${hard_errors_count} -gt 0 ]]; then
> > eerror "Please check to make sure these options are set
> > correctly."
> > eerror "Failure to do so may cause unexpected problems."
> > eerror "Once you have satisfied these options, please try
> > merging"
> > eerror "this package again."
> > export
> > LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
> > die "Incorrect kernel configuration options"
> > - elif [[ ${soft_errors_count} > 0 ]]; then
> > + elif [[ ${soft_errors_count} -gt 0 ]]; then
> > ewarn "Please check to make sure these options are set
> > correctly."
> > ewarn "Failure to do so may cause unexpected problems."
> > else
> >
>
> Thanks. LGTM
Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa1d259decdfd73a49e0c49e88a8ec5675453266
--
Sergei
[gentoo-dev] Re: [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558
On Fri, 22 May 2020 23:42:48 +0100
Sergei Trofimovich wrote:
> For both multilib and non-multilib profiles binutils provides
> tools with native ABI prefix only. For example on amd64 there
> is only 'x86_64-pc-linux-gnu-nm' and 'nm'.
>
> On abi_x86_32 tools are usually configured with --host=i686-pc-linux-gnu.
> Configure tries i686-pc-linux-gnu-nm, then falls back to 'nm'.
>
> The change overrides NM to 'x86_64-pc-linux-gnu-nm' for
> multilib setup similar to other environment variables.
>
> Reported-by: Kent Fredric
> Closes: https://bugs.gentoo.org/724558
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/multilib.eclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index bbaab709b4f..25e90dea44c 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -484,11 +484,13 @@ multilib_toolchain_setup() {
> # Set the CHOST native first so that we pick up the native
> # toolchain and not a cross-compiler by accident #202811.
> export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
> + export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
> export CC="$(tc-getCC) $(get_abi_CFLAGS)"
> export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
> export F77="$(tc-getF77) $(get_abi_CFLAGS)"
> export FC="$(tc-getFC) $(get_abi_CFLAGS)"
> export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
> + export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
> export CHOST=$(get_abi_CHOST $1)
> export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
> export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
Also added OBJDUMP, RANLIB and STRIP as they are used in most
libraries used by autotools. Pushed as:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd35b529194fdcadf324fd4f0a466a61aa1dfadb
--
Sergei
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, 23 May 2020 08:05:46 +0200
Michał Górny wrote:
> On Fri, 2020-05-22 at 22:36 +0100, Sergei Trofimovich wrote:
> > 'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
> > packages that don't respect users' CC/AR/LD flags.
> >
> > I added new USE=-native-symlinks mode for gcc-config and
> > binutils-config to ease detection of such packages.
> >
> > Native symlinks are still installed by default. Nothing should
> > break for users who use default USE flags.
> >
> > USE=-native-symlinks removes a bunch of links that most packages
> > use by default until are overridden explicitly. Incomplete list is:
> > - /lib/cpp
> > - /usr/bin/{gcc,cc,g++,c++,...}
> > - /usr/bin/{as,ld,ranlib,dwp,...}
> >
> > The rule of thumb is: if a tool does not have ${CTARGET}- prefix
> > it will probably disappear with USE=-native-symlinks.
>
> Does this list include 'ar' or not? Asking because there's been
> a number of false positives reported for 'ar' being used as an archiver
> (e.g. to work on .deb packages).
USE=-native-symlinks does remove /usr/bin/ar. Full(er) list for binutils is:
addr2line
ar
as
c++filt
coffdump
dlltool
dllwrap
dwp
elfedit
gprof
ld
ld.bfd
ld.gold
nm
objcopy
objdump
ranlib
readelf
size
srconv
strings
strip
sysdump
windmc
windres
--
Sergei
[gentoo-dev] [PATCH] multilib.eclass: populate AR and NM in multilib_toolchain_setup(), bug #724558
For both multilib and non-multilib profiles binutils provides
tools with native ABI prefix only. For example on amd64 there
is only 'x86_64-pc-linux-gnu-nm' and 'nm'.
On abi_x86_32 tools are usually configured with --host=i686-pc-linux-gnu.
Configure tries i686-pc-linux-gnu-nm, then falls back to 'nm'.
The change overrides NM to 'x86_64-pc-linux-gnu-nm' for
multilib setup similar to other environment variables.
Reported-by: Kent Fredric
Closes: https://bugs.gentoo.org/724558
Signed-off-by: Sergei Trofimovich
---
eclass/multilib.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index bbaab709b4f..25e90dea44c 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -484,11 +484,13 @@ multilib_toolchain_setup() {
# Set the CHOST native first so that we pick up the native
# toolchain and not a cross-compiler by accident #202811.
export CHOST=$(get_abi_CHOST ${DEFAULT_ABI})
+ export AR="$(tc-getAR)" # Avoid 'ar', use '${CHOST}-ar'
export CC="$(tc-getCC) $(get_abi_CFLAGS)"
export CXX="$(tc-getCXX) $(get_abi_CFLAGS)"
export F77="$(tc-getF77) $(get_abi_CFLAGS)"
export FC="$(tc-getFC) $(get_abi_CFLAGS)"
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
+ export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
--
2.26.2
[gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
'tc-directly' tracker https://bugs.gentoo.org/243502 tracks
packages that don't respect users' CC/AR/LD flags.
I added new USE=-native-symlinks mode for gcc-config and
binutils-config to ease detection of such packages.
Native symlinks are still installed by default. Nothing should
break for users who use default USE flags.
USE=-native-symlinks removes a bunch of links that most packages
use by default until are overridden explicitly. Incomplete list is:
- /lib/cpp
- /usr/bin/{gcc,cc,g++,c++,...}
- /usr/bin/{as,ld,ranlib,dwp,...}
The rule of thumb is: if a tool does not have ${CTARGET}- prefix
it will probably disappear with USE=-native-symlinks.
(At least eventually) 'emerge' should still be able to build most
of packages in such environment. I expect initial breakage will be
huge though.
Using './configure && make && make install' style workflow will be more
tedious. One workaround at least for gcc is to use something like:
$ PATH="$(gcc-config -B):$PATH"
It's not perfect. We'll see if toolchain can provide nicer environment.
Typical fixes for autoconf style build systems is to use macros like:
- AC_PROG_CC
- AM_PROG_AR
- AC_CHECK_TOOL(DWP, dwp)
and so on to detect tool that corresponds to --host=/--target= flags
and allows user's override via environment variable.
--
Sergei
[gentoo-dev] [PATCH] 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.
CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705246
Signed-off-by: Sergei Trofimovich
---
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..d69182045c5 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
[gentoo-dev] [PATCH] linux-info.eclass: avoid lexicographical compare on numbers, bug #705248
Originally found in bug #705240 as:
```
error=0
...
if [[ ${error} > 0 ]]; then
...
```
'>' are string comparisons. They are benign in this case, but let's
be consistent and use integer comparison.
CC: ker...@gentoo.org
Closes: https://bugs.gentoo.org/705248
Signed-off-by: Sergei Trofimovich
---
eclass/linux-info.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 44eebcf52a9..405ef5571e1 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -813,7 +813,7 @@ check_extra_config() {
linux_chkconfig_present ${config} || error=1
fi
- if [[ ${error} > 0 ]]; then
+ if [[ ${error} -gt 0 ]]; then
local report_func="eerror" local_error
local_error="ERROR_${config}"
local_error="${!local_error}"
@@ -848,14 +848,14 @@ check_extra_config() {
fi
done
- if [[ ${hard_errors_count} > 0 ]]; then
+ if [[ ${hard_errors_count} -gt 0 ]]; then
eerror "Please check to make sure these options are set
correctly."
eerror "Failure to do so may cause unexpected problems."
eerror "Once you have satisfied these options, please try
merging"
eerror "this package again."
export
LINUX_CONFIG_EXISTS_DONE="${old_LINUX_CONFIG_EXISTS_DONE}"
die "Incorrect kernel configuration options"
- elif [[ ${soft_errors_count} > 0 ]]; then
+ elif [[ ${soft_errors_count} -gt 0 ]]; then
ewarn "Please check to make sure these options are set
correctly."
ewarn "Failure to do so may cause unexpected problems."
else
--
2.26.2
[gentoo-dev] gcc-10 is in ~arch
gcc-10 was released yesterday and was pushed to ::gentoo's ~arch as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=32258c6414a31898ff5592893678a3910d2c5c75 Most of packages should Just Work. But we expect some amount of build- and runtime breakage. Non-exhaustive list of things to watch for: - missing includes in users' code Example build failure would be: "error: 'size_t' was not declared in this scope; did you mean 'std::size_t'?" where missing for used size_t types. - extra '-fcommon->-fno-common' linker failures for packages that ignore users' CFLAGS and thus missed Toralf's tinderbox runs. https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common - "9" -> "10" version change also managed to break many assumptions of how gcc versions are parsed by shell scripts and ebuilds. This causes all sorts of bizarre bugs: https://trofi.github.io/posts/213-gcc-10-in-gentoo.html - overhauled gcc-10 inliner heuristics will cause some amount of build/runtime breakage in existing fragile code. As an extreme example your stack-protected kernel might not boot: https://lkml.org/lkml/2020/3/14/186 Tracker of common breakages: https://bugs.gentoo.org/show_bug.cgi?id=gcc-10 Landing page to steal-fixes-from/add-fixes-to: https://wiki.gentoo.org/wiki/Project:Toolchain#gcc-10 If you can't figure out non-trivial breakage feel free to add toolchain@ to the bug and we'll try to sort it out together. -- Sergei
Re: [gentoo-dev] CFLAGS=-fno-common related breakage is incoming
On Sun, 19 Jan 2020 22:36:51 +
Sergei Trofimovich wrote:
> > What is happening?
>
> gcc-10 is coming soon. It will be more disruptive than gcc-9.
>
> One of the major changes is the switch from C{,XX}FLAGS=-fcommon
> to C{,XX}FLAGS=-fno-common by default: https://gcc.gnu.org/PR85678
>
> It's a planned change and not a gcc regression. It will expose some
> warts on old code and unblock minor optimisations accessing globals.
>
> The change has already happened in gcc trunk.
>
> > Is my package affected? Should I do anything?
>
> You can check proactively if your packages are affected.
>
> Add -fno-common to your make.conf's C{,XX}FLAGS and
> see if things still build.
>
> The typical symptom is a linker failure on multiple definitions
> for some global variable:
>
> ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0):
> first defined here
>
> > How to fix it?
>
> https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common contains
> some examples. Ideally code will need a few 'extern' additions and maybe
> moving variable definitions.
>
> Example of proposed openrc fix:
> https://github.com/OpenRC/openrc/pull/348
>
> Adding 'append-flags -fcommon' might work as a temporary workaround.
>
> > Can I help?
>
> Glad you asked! We will need to gather failed packages and fix them
> upstream and downstream. Here is what you can do:
>
> 1. Add -fno-common to your make.conf's C{,XX}FLAGS
> 2. Build packages you maintain
> 3. Fix a bug upstream (or report a failure).
> 4. Pull a fix downstream (or file a bug and add it to the tracker).
>
> > What is already known to be broken? Can I look at example fixes?
>
> See https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common
> for an artificial example.
>
> Gentoo tracker bug of known issues:
> https://bugs.gentoo.org/705764
> 15 bugs so far.
>
> SUSE tracker bug of known issues:
> https://bugzilla.suse.com/show_bug.cgi?id=1160244
> 95 bugs so far. A good source of packages to check against the
> ones you care about.
>
> > What does -fcommon do?
>
> Look up -fcommon in https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
>
> > I have no idea why my package broke. The error does not make sense.
>
> Feel free to CC toolchain@ on a bug you observe and we'll try to sort it out.
With Toralf's help we now have rough estimate of broken packages. It's about
450 yet unfixed ones:
https://bugs.gentoo.org/showdependencytree.cgi?id=705764_resolved=1
gcc-10 will be released soon. Maybe in a week.
Please look at the broken list and fix your packages.
Thanks!
--
Sergei
Re: [gentoo-dev] [PATCH] rebar.eclass: Use := dependency
On Sat, 25 Apr 2020 10:01:50 +0200
Hanno Böck wrote:
> All erlang rebar based packages should be rebuilt after a subslot
> update of dev-lang/erlang.
>
> Right now this is done in some ebuilds, but inconsistent.
> Given this affects all packages this should be reflected in the
> rebar.eclass, see also [1].
>
> [1] https://bugs.gentoo.org/714702
>
> Closes: https://bugs.gentoo.org/714702
> Signed-off-by: Hanno Böck
> ---
>
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> index f2a620fd8..92dd16b08 100644
> --- a/eclass/rebar.eclass
> +++ b/eclass/rebar.eclass
> @@ -32,7 +32,7 @@ esac
>
> EXPORT_FUNCTIONS src_prepare src_compile src_test src_install
>
> -RDEPEND="dev-lang/erlang"
> +RDEPEND="dev-lang/erlang:="
> DEPEND="${RDEPEND}
> dev-util/rebar
> >=sys-apps/gawk-4.1"
>
> --
> Hanno Böck
> https://hboeck.de/
>
Looks good.
--
Sergei
[gentoo-dev] */*: downgrade m68k down to ~m68k
With https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dce3dc0aa1341155a31407122e079632fcd07ca m68k does not have stable keywords in ::gentoo anymore and thus becomes ~arch-only Gentoo target. """ */*: downgrade m68k down to ~m68k m68k and ~m68k trees are inconsistent. Let's drop keywords down to ~m68k only. Profiles already accept both keywords: ACCEPT_KEYWORDS="m68k ~m68k" """ Even basic packages don't have consistent ~m68k keywords. I don't think stable keywords have any use today. I will pass through and un-CC/close all STABLEREQ bugs where m68k is CCed. -- Sergei
[gentoo-dev] Package up for grabs: dev-libs/ppl
Single fresh test failure bug: https://bugs.gentoo.org/717258. commit f054fd75ab013787e2c65438998067de00de04e5 Author: Sergei Trofimovich Date: Mon Apr 13 09:52:03 2020 +0100 dev-libs/ppl: drop toolchain from maintainers gcc's graphite does not use dev-libs/ppl for loop optimizations for a while. -- Sergei
Re: [gentoo-dev] [PATCH] enable build of gnat compiler in the toolchain eclass
On Fri, 3 Apr 2020 08:25:35 +0200 Tupone Alfredo wrote: > --- > eclass/toolchain.eclass | 25 ++--- > 1 file changed, 22 insertions(+), 3 deletions(-) Looks good! -- Sergei
[gentoo-dev] Re: Changes to toolchain.eclass to better support gnat-gpl ebuild
On Thu, 2 Apr 2020 12:52:13 +0200
Alfredo Tupone wrote:
> + # Do not set ADAFLAGS to build the compiler
> + unset ADAFLAGS
Can you clarify in a comment why it's done?
> # Older gcc versions did not detect bash and re-exec itself, so force
> the
> # use of bash. Newer ones will auto-detect, but this is not harmful.
> # This needs to be set for compile as well, as it's used in libtool
> # generation, which will break install otherwise (at least in 3.3.6):
> #664486
> CONFIG_SHELL="${EPREFIX}/bin/bash" \
> gcc_do_make ${GCC_MAKE_TARGET}
> + if use ada; then
> + gcc_do_make "-C gcc gnatlib-shared"
> + ln -s gcc ../build/prev-gcc || die
> + ln -s ${CHOST} ../build/prev-${CHOST} || die
> + gcc_do_make "-C gcc gnattools"
> + fi
Two points:
1. You probably still need CONFIG_SHELL="${EPREFIX}/bin/bash" passed.
2. Can you add an inline comment why it's needed? Why 'make' does not Just Work?
--
Sergei
Re: [gentoo-dev] [PATCH 2/2] multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl*
On Sat, 28 Mar 2020 11:19:29 -0400 Mike Gilbert wrote: > On Sat, Mar 28, 2020 at 5:40 AM Sergei Trofimovich wrote: > > > > In contrast to glibc musl profiles use 'lib' layour for 32-bit > > and 64-bit targets. multilib_env() did not take it into account > > and assumed glibc's lib64 layout. > > > > That breaks crossdev as it uses multilib_env to extract target > > definition. Native builds are unaffected by this change. > > > > Bug: https://bugs.gentoo.org/675954 > > Bug: https://gcc.gnu.org/PR90077 > > Bug: https://github.com/gentoo/musl/issues/245 > > Signed-off-by: Sergei Trofimovich > > Please also update the copyright notice in multilib.eclass while you're at it. Updated as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a687fd280c3d33cbf7ef99cd6f96fda95039c75 -- Sergei
Re: [gentoo-dev] [PATCH 1/2] eclass/tests: add basic tests for multilib_env() expansion
On Sat, 28 Mar 2020 11:17:42 -0400 Mike Gilbert wrote: > > --- /dev/null > > +++ b/eclass/tests/multilib.sh > > @@ -0,0 +1,61 @@ > > +#!/bin/bash > > +# Copyright 1999-2020 Gentoo Foundation > > This should say "Copyright 2020 Gentoo Authors". ... > > +# Pick a few interesting gargets from: > > Probably a typo: s/gargets/targets/ God point! Tweaked both as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1a687fd280c3d33cbf7ef99cd6f96fda95039c75 -- Sergei
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: add some missing MIPS CPU errata options to ALLOWED_FLAGS
On Sat, 28 Mar 2020 15:17:12 -0400
Joshua Kinard wrote:
> Noticed during a glibc build for MIPS-III ISA that the -mfix-r4000
> and -mfix-r4400 gcc flags got stripped off. These are needed to work
> around known CPU errata in R4000 and R4400 CPUs. In addition, also
> add the -mfix-rm7000 option (and it's -mno form) to fix errata in the
> PMC RM7000 CPU, and the -mr10k-cache-barrier to control the generation
> of cache barriers to work around the side-effects of R1's
> speculative execution capabilities.
>
> Signed-off-by: Joshua Kinard
> ---
> eclass/flag-o-matic.eclass | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
> index e76eef293e..0c67ec9f7a 100644
> --- a/eclass/flag-o-matic.eclass
> +++ b/eclass/flag-o-matic.eclass
> @@ -56,7 +56,9 @@ setup-allowed-flags() {
> -mno-faster-structs -mfaster-structs -m32 -m64 -mx32 -mabi
> -mlittle-endian -mbig-endian -EL -EB -fPIC -mlive-g0 -mcmodel
> -mstack-bias -mno-stack-bias -msecure-plt '-m*-toc' -mfloat-abi
> - -mfix-r1 -mno-fix-r1 -mthumb -marm
> + -mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400
> + -mfix-rm7000 -mno-fix-rm7000 -mfix-r1 -mno-fix-r1
> + -mr10k-cache-barrier -mthumb -marm
>
> # gcc 4.5
> -mno-fma4 -mno-movbe -mno-xop -mno-lwp
Looks good!
--
Sergei
[gentoo-dev] [PATCH 2/2] multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl*
In contrast to glibc musl profiles use 'lib' layour for 32-bit
and 64-bit targets. multilib_env() did not take it into account
and assumed glibc's lib64 layout.
That breaks crossdev as it uses multilib_env to extract target
definition. Native builds are unaffected by this change.
Bug: https://bugs.gentoo.org/675954
Bug: https://gcc.gnu.org/PR90077
Bug: https://github.com/gentoo/musl/issues/245
Signed-off-by: Sergei Trofimovich
---
eclass/multilib.eclass | 13 -
eclass/tests/multilib.sh | 4
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 63bde5cbb60..8b4a7dacaa3 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -294,11 +294,22 @@ get_modname() {
}
# This is for the toolchain to setup profile variables when pulling in
-# a crosscompiler (and thus they aren't set in the profile)
+# a crosscompiler (and thus they aren't set in the profile).
multilib_env() {
local CTARGET=${1:-${CTARGET}}
local cpu=${CTARGET%%*-}
+ if [[ ${CTARGET} = *-musl* ]]; then
+ # musl has no multilib support and can run only in 'lib':
+ # - https://bugs.gentoo.org/675954
+ # - https://gcc.gnu.org/PR90077
+ # - https://github.com/gentoo/musl/issues/245
+ : ${MULTILIB_ABIS=default}
+ : ${DEFAULT_ABI=default}
+ export MULTILIB_ABIS DEFAULT_ABI
+ return
+ fi
+
case ${cpu} in
aarch64*)
# Not possible to do multilib with aarch64 and a single
toolchain.
diff --git a/eclass/tests/multilib.sh b/eclass/tests/multilib.sh
index 308c456b98d..68c0dd6e142 100755
--- a/eclass/tests/multilib.sh
+++ b/eclass/tests/multilib.sh
@@ -57,5 +57,9 @@ test-multilib_env \
"x86_64-pc-linux-gnux32" \
"x32:x32 amd64 x86" \
"x32? ( CHOST=x86_64-pc-linux-gnux32 LIBDIR=libx32 CFLAGS=-mx32
LDFLAGS= ) amd64? ( CHOST=x86_64-pc-linux-gnu LIBDIR=lib64 CFLAGS=-m64 LDFLAGS=
) x86? ( CHOST=i686-pc-linux-gnu LIBDIR=lib CFLAGS=-m32 LDFLAGS= )"
+test-multilib_env \
+ "x86_64-gentoo-linux-musl" \
+ "default:default" \
+ "default? ( CHOST=x86_64-gentoo-linux-musl LIBDIR=lib CFLAGS= LDFLAGS=
)"
texit
--
2.26.0
