[gentoo-dev] [PATCH 2/4] autotools.eclass: use --system-acdir for aclocal
We need to instruct aclocal that it might find macros in both
${BROOT} _and_ ${SYSROOT}.
- A classic example within BROOT is autoconf-archive.
- A classic example within SYSROOT is, say, libogg. A fair amount of
codec software installs its own macro to help locating it (but this
is in no ways limited to that genre/area).
The correct position for a dependency like libogg is DEPEND, and yet
the status quo doesn't mean that aclocal is obligated to check in ${ESYSROOT}
which is where DEPEND-class dependencies are guaranteed to be installed.
We can't rely on these being in BDEPEND -- in fact, most of the time,
they won't be. If we wanted to rely on macros always being provided by
BDEPEND, we'd have to duplicate a considerable number of dependencies
in both BDEPEND + DEPEND, with the unnecessary cross-compilation that would
entail too: it makes far more sense to just tell aclocal to look in the
right place (an extra location).
Bug: https://bugs.gentoo.org/710792
Closes: https://bugs.gentoo.org/677002
Closes: https://bugs.gentoo.org/738918
Thanks-to: David Michael (for the suggestion)
Thanks-to: James Le Cuirot (rubberducking & sounding board)
Signed-off-by: Sam James
---
eclass/autotools.eclass | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index e2572290f0cbe..2cf7c076d01ed 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -332,8 +332,22 @@ eaclocal_amflags() {
# They also force installing the support files for safety.
# Respects AT_M4DIR for additional directories to search for macros.
eaclocal() {
+ # Feed in a list of paths:
+ # - ${BROOT}/usr/share/aclocal
+ # - ${ESYSROOT}/usr/share/aclocal
+ # See bug #677002
+ if [[ ! -f "${T}"/aclocal/dirlist ]] ; then
+ mkdir "${T}"/aclocal || die
+ cat <<- EOF > "${T}"/aclocal/dirlist || die
+ ${BROOT}/usr/share/aclocal
+ ${ESYSROOT}/usr/share/aclocal
+ EOF
+ fi
+
+ local system_acdir=" --system-acdir=${T}/aclocal"
+
[[ ! -f aclocal.m4 || -n $(grep -e 'generated.*by aclocal' aclocal.m4)
]] && \
- autotools_run_tool --at-m4flags aclocal "$@" $(eaclocal_amflags)
+ autotools_run_tool --at-m4flags aclocal "$@"
$(eaclocal_amflags) ${system_acdir}
}
# @FUNCTION: _elibtoolize
--
2.34.1
[gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal
When -I${SYSROOT} is injected, it'll override the default of -Im4, which
results in trying to install macros to ${SYSROOT} (a sandbox violation)
when they can't be found.
>From aclocal(1):
```
-I DIR add directory to search list for .m4 files
--install
copy third-party files to the first -I directory
```
The first directry is normally -Im4 if anything, whereas when injected
(when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
we try to copy macros to somewhere outside of the build directory).
In EAPI 7+, this is almost always the case! We don't generally expect
to find macros (particularly things like autoconf-archive) in ${SYSROOT}
because that's for DEPEND-class dependencies, then they end up being
copied in unnecessarily and wrongly.
We could drop this just for < EAPI 7, but I'm not sure there's much
point there either. As Chewi observed in bug 677002, you can't
assume they'll be present in ${SYSROOT} anyway, and frankly,
the cross-compilation (and --root, --sysroot, and so on) situation
is rather bleak for earlier EAPIs, which is why we did all that
work for 7.
Bug: https://bugs.gentoo.org/710792
Closes: https://bugs.gentoo.org/677002
Closes: https://bugs.gentoo.org/738918
Thanks-to: James Le Cuirot
Signed-off-by: Sam James
---
eclass/autotools.eclass | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 95c92cc6df8ca..e2572290f0cbe 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2021 Gentoo Authors
+# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: autotools.eclass
@@ -666,12 +666,6 @@ autotools_m4sysdir_include() {
# First try to use the paths the system integrator has set up.
local paths=( $(eval echo ${AT_SYS_M4DIR}) )
- if [[ ${#paths[@]} -eq 0 && -n ${SYSROOT} ]] ; then
- # If they didn't give us anything, then default to the SYSROOT.
- # This helps when cross-compiling.
- local path="${SYSROOT}/usr/share/aclocal"
- [[ -d ${path} ]] && paths+=( "${path}" )
- fi
_autotools_m4dir_include "${paths[@]}"
}
--
2.34.1
[gentoo-dev] [PATCH 4/4] autotools.eclass: update for autoconf 2.71
Closes: https://bugs.gentoo.org/827852
Signed-off-by: Sam James
---
eclass/autotools.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 5250b28042ee2..5568cca505d78 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -95,7 +95,7 @@ if [[ -n ${WANT_AUTOCONF} ]] ; then
none) _autoconf_atom="" ;; # some packages don't require
autoconf at all
2.1)_autoconf_atom="~sys-devel/autoconf-2.13" ;;
# if you change the "latest" version here, change also
autotools_env_setup
- latest|2.5) _autoconf_atom=">=sys-devel/autoconf-2.69" ;;
+ latest|2.5) _autoconf_atom=">=sys-devel/autoconf-2.71" ;;
*) die "Invalid WANT_AUTOCONF value
'${WANT_AUTOCONF}'" ;;
esac
export WANT_AUTOCONF
@@ -524,7 +524,7 @@ autotools_env_setup() {
[[ ${WANT_AUTOMAKE} == "latest" ]] && \
die "Cannot find the latest automake! Tried
${_LATEST_AUTOMAKE[*]}"
fi
- [[ ${WANT_AUTOCONF} == "latest" ]] && export WANT_AUTOCONF=2.5
+ [[ ${WANT_AUTOCONF} == "latest" ]] && export WANT_AUTOCONF=2.71
}
# @FUNCTION: autotools_run_tool
--
2.34.1
[gentoo-dev] [PATCH 3/4] autotools.eclass: update for latest automake 1.16.4
Signed-off-by: Sam James --- eclass/autotools.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass index 2cf7c076d01ed..5250b28042ee2 100644 --- a/eclass/autotools.eclass +++ b/eclass/autotools.eclass @@ -74,7 +74,7 @@ inherit gnuconfig libtool # Do NOT change this variable in your ebuilds! # If you want to force a newer minor version, you can specify the correct # WANT value by using a colon: : -_LATEST_AUTOMAKE=( 1.16.2-r1:1.16 ) +_LATEST_AUTOMAKE=( 1.16.4:1.16 ) _automake_atom="sys-devel/automake" _autoconf_atom="sys-devel/autoconf" -- 2.34.1
Re: [gentoo-dev] [PATCH 2/4] autotools.eclass: use --system-acdir for aclocal
> On 17 Jan 2022, at 11:09, Sam James wrote:
>
> We need to instruct aclocal that it might find macros in both
> ${BROOT} _and_ ${SYSROOT}.
>
> - A classic example within BROOT is autoconf-archive.
>
> - A classic example within SYSROOT is, say, libogg. A fair amount of
> codec software installs its own macro to help locating it (but this
> is in no ways limited to that genre/area).
>
> The correct position for a dependency like libogg is DEPEND, and yet
> the status quo doesn't mean that aclocal is obligated to check in ${ESYSROOT}
> which is where DEPEND-class dependencies are guaranteed to be installed.
>
> We can't rely on these being in BDEPEND -- in fact, most of the time,
> they won't be. If we wanted to rely on macros always being provided by
> BDEPEND, we'd have to duplicate a considerable number of dependencies
> in both BDEPEND + DEPEND, with the unnecessary cross-compilation that would
> entail too: it makes far more sense to just tell aclocal to look in the
> right place (an extra location).
>
> Bug: https://bugs.gentoo.org/710792
> Closes: https://bugs.gentoo.org/677002
> Closes: https://bugs.gentoo.org/738918
> Thanks-to: David Michael (for the suggestion)
> Thanks-to: James Le Cuirot (rubberducking & sounding board)
> Signed-off-by: Sam James
> ---
> eclass/autotools.eclass | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
> index e2572290f0cbe..2cf7c076d01ed 100644
> --- a/eclass/autotools.eclass
> +++ b/eclass/autotools.eclass
> @@ -332,8 +332,22 @@ eaclocal_amflags() {
> # They also force installing the support files for safety.
> # Respects AT_M4DIR for additional directories to search for macros.
> eaclocal() {
> + # Feed in a list of paths:
> + # - ${BROOT}/usr/share/aclocal
> + # - ${ESYSROOT}/usr/share/aclocal
> + # See bug #677002
> + if [[ ! -f "${T}"/aclocal/dirlist ]] ; then
> + mkdir "${T}"/aclocal || die
> + cat <<- EOF > "${T}"/aclocal/dirlist || die
> + ${BROOT}/usr/share/aclocal
> + ${ESYSROOT}/usr/share/aclocal
> + EOF
> + fi
> +
> + local system_acdir=" --system-acdir=${T}/aclocal"
> +
> [[ ! -f aclocal.m4 || -n $(grep -e 'generated.*by aclocal' aclocal.m4)
> ]] && \
> - autotools_run_tool --at-m4flags aclocal "$@" $(eaclocal_amflags)
> + autotools_run_tool --at-m4flags aclocal "$@"
> $(eaclocal_amflags) ${system_acdir}
> }
I've changed this locally to just skip the add-system-acdir-logic for older
EAPIs. Forgot to amend the commit,
Chewi had already pointed this out privately.
best,
sam
signature.asc
Description: Message signed with OpenPGP
[gentoo-dev] [python] PEP 517 migration
Hi, everyone. I've added a short PEP 517 migration guide to the docs [1]. This should work for the vast majority of packages using distutils-r1, as long as they don't use too many hacks. For things like numpy or pillow we'll have to figure out individual solutions. In general, there's no need for urgent migration. I'm slowly migrating Python packages on version bumps. Note that the dependencies haven't been keyworded on ~alpha yet. Long story short, to migrate you: 1. Add DISTUTILS_USE_PEP517= with the list of supported build systems being defined in the eclassdoc (right now: flit, pdm, poetry, setuptools). For pure distutils we also use setuptools. Don't use standalone, that's internal python@ stuff. 2. Remove DISTUTILS_USE_SETUPTOOLS. If you still need RDEPEND on setuptools (i.e. the package imports setuptools or pkg_resources), add it explicitly. 3. Remove distutils_install_for_testing (or --install arg to distutils_enable_tests). This should no longer be necessary, we supply venv-style install tree out of the box. IMPORTANT: please verify installed file list, Python upstream doesn't care much about backwards compatibility and this can break stuff. app-portage/iwdevtools can be helpful in checking file list on bumps. Please lemme know if you hit any issues. [1] https://dev.gentoo.org/~mgorny/python-guide/migration.html#migrating-to-pep-517-builds -- Best regards, Michał Górny
Re: [gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)
On 8.1.2022 7.12, Sam James wrote: > > FWIW, normally we don't post individual package patches > to this ML, but it's a good question as to.. where they should go > if people want to use git send-email/a ML workflow. > > Right now, sometimes people send them to gentoo-proxy-maint > (the list) which the proxy maintainers team that handles > most user contributions looks at, but I'll be honest and say > our workflow isn't really optimised for it given it's used > pretty infrequently. > > Makes me wonder if we should rename the list > or have a separate one (gentoo-patches?). > > (Or just use that list and make sure people CC > maintainers as you did here?) > > Best, > sam I don't think setting up a new mailing list purely for patches will benefit much. It all comes down to who's gonna merge the contributions, and Github/bugzilla are definitely easier in that regard. I suggest opening a bug like normally, and then sending the .patch to the maintainers directly via e-mail with bug #nr linked either in Subject or git message body. -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Hi,
I've been approached multiple times with that request, and a lot of
time I see new users completely destroyed by rust build time and disk
space requirements.
WDYT about switching order of rusts in a virtual?
RDEPEND="|| (
~dev-lang/rust-${PV}
~dev-lang/rust-bin-${PV}
)"
becomes
RDEPEND="|| (
~dev-lang/rust-bin-${PV}
~dev-lang/rust-${PV}
)"
Existing installs should be unaffected ofc.
But portage may prefer to depclean rust and not rust-bin if both are
present.
Users who wish to use source version at all times can just add it to
world file.
I see both positives and negatives of doing that, but would like to
reach out to community first.
Thanks!
--
Georgy
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Georgy Yakovlev wrote:
> Hi,
>
> I've been approached multiple times with that request, and a lot of
> time I see new users completely destroyed by rust build time and disk
> space requirements.
>
> WDYT about switching order of rusts in a virtual?
>
> RDEPEND="|| (
> ~dev-lang/rust-${PV}
> ~dev-lang/rust-bin-${PV}
> )"
>
>
> becomes
>
> RDEPEND="|| (
> ~dev-lang/rust-bin-${PV}
> ~dev-lang/rust-${PV}
> )"
>
>
> Existing installs should be unaffected ofc.
> But portage may prefer to depclean rust and not rust-bin if both are
> present.
> Users who wish to use source version at all times can just add it to
> world file.
>
> I see both positives and negatives of doing that, but would like to
> reach out to community first.
>
> Thanks!
>
> --
> Georgy
>
>
As a user, if I recall correctly, if a user wants rust-bin, all they
have to do is emerge -1 rust-bin and then let whatever package pull in
the virtual for rust. The virtual will be satisfied and rust-bin will
be used. From my understanding, that is the purpose of virtuals,
allowing users to pick what they want to use to satisfy the
requirement. I wouldn't want either rust in my world file as it is not
a package I use directly. It should be a dependency of another package,
such as Firefox. To me, this sounds like there should be a note added to
a install guide so new users are aware of this, provided it isn't
already mentioned.
Gentoo is known for compiling from sources. Defaulting to a package
that is a binary but available as a package from source that requires
compiling, that would be unexpected.
Just my $0.02 worth, as a user.
Dale
:-) :-)
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On Mon, 2022-01-17 at 21:58 -0500, Ionen Wolkens wrote:
> On Mon, Jan 17, 2022 at 03:24:23PM -0800, Georgy Yakovlev wrote:
> > Hi,
> >
> > I've been approached multiple times with that request, and a lot of
> > time I see new users completely destroyed by rust build time and
> > disk
> > space requirements.
>
> fwiw it may be a bit mitigated by the new desktop stages that come
> with
> rust, or at least it won't be the first thing they see when they try
> to build their brand new desktop install until a rust update.
>
> It's nice if users can get a basic desktop before worrying about how
> to
> handle rust. Not that desktop stages are heavily visible/known so new
> users may not always pick them.
indeed it helps, but it takes time for users to discover/consider this.
it mostly hits very new users or users of containers/vms, who don't
have enough disk space or ram.
>
> >
> > WDYT about switching order of rusts in a virtual?
> >
> > RDEPEND="|| (
> > ~dev-lang/rust-${PV}
> > ~dev-lang/rust-bin-${PV}
> > )"
> >
> >
> > becomes
> >
> > RDEPEND="|| (
> > ~dev-lang/rust-bin-${PV}
> > ~dev-lang/rust-${PV}
> > )"
> >
> >
> > Existing installs should be unaffected ofc.
> > But portage may prefer to depclean rust and not rust-bin if both
> > are
> > present.
>
> Haven't tested how it reacts, but wouldn't that be an issue with
> system-bootstrap in situations where it pulls rust-bin to build
> itself?
it can build itself with non-bin too. as long as it's same or ver-
minus-1 and is installed, if not installed it will pull rust-bin of
matching version.
also system-bootstrap is stable-masked (for various reasons), so I'm
not too worried about it. ~kw users know their way around.
>
> > Users who wish to use source version at all times can just add it
> > to
> > world file.
> >
> > I see both positives and negatives of doing that, but would like to
> > reach out to community first.
>
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few
> days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
>
If I had clear answer myself I would not be asking opinions here =)
just trying to understand if I'm missing something or my view is too
different.
developer and user opinions all are helpful to build picture.
I receive at least weekly complaint about how resource-intensive rust
build is, that counts too.
for now on stable systems, if user types, let's say,
$ emerge ripgrep
with USE=-system-bootsrap (the default):
portage will pull virtual/rust, which will pull dev-lang/rust, which
will bootstrap itself by downloading proper rust-bin tarball, but not
as a package, just as a tarball behind the scenes.
with USE=system-bootstrap:
portage will pull virtual/rust, which will pull dev-lang/rust-bin, and
build dev-lang/rust, to build ripgrep.
USE=system-llvm (also stable-masked) complicates picture even more.
We've had openjdk-bin and icedtea-bin as default provider for as long
as I can remember, before I started to maintain it. works fine.
PS:
and just to be clear - I'm not pushing for it, just asking for input.
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 18.1.2022 4.58, Ionen Wolkens wrote:
>
> Unsure what I like best, I generally agree should default to sources
> but I do see new users complaining about building rust every few days.
> Not that the step of telling them that rust-bin exists is that bad
> (part of the issue is that they don't know it's an option).
>
Indeed, can see both ways. On my desktop I use rust, and on my
laptop+containers rust-bin. Having to package.mask rust so rust-bin gets
pulled might not be the first thing new users are aware.
To make things more complicated...
IUSE="+binary"
RDEPEND="binary? ( ~dev-lang/rust-bin-${PV} )
!binary? ( ~dev-lang/rust-${PV} )"
or "+pre-compiled" or something ;)
-- juippis
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Hi, On 2022/01/18 04:58, Ionen Wolkens wrote: > > Unsure what I like best, I generally agree should default to sources > but I do see new users complaining about building rust every few days. > Not that the step of telling them that rust-bin exists is that bad > (part of the issue is that they don't know it's an option). > Perhaps output a notice in rust's pkg_setup() that you're using the source version and that it takes a long time to build, and consumes lots of resources and you may want to consider rust-bin? Possibly with some variable in make.conf or some USE to turn that off? Kind Regards, Jaco
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On Mon, Jan 17, 2022 at 03:24:23PM -0800, Georgy Yakovlev wrote:
> Hi,
>
> I've been approached multiple times with that request, and a lot of
> time I see new users completely destroyed by rust build time and disk
> space requirements.
fwiw it may be a bit mitigated by the new desktop stages that come with
rust, or at least it won't be the first thing they see when they try
to build their brand new desktop install until a rust update.
It's nice if users can get a basic desktop before worrying about how to
handle rust. Not that desktop stages are heavily visible/known so new
users may not always pick them.
>
> WDYT about switching order of rusts in a virtual?
>
> RDEPEND="|| (
> ~dev-lang/rust-${PV}
> ~dev-lang/rust-bin-${PV}
> )"
>
>
> becomes
>
> RDEPEND="|| (
> ~dev-lang/rust-bin-${PV}
> ~dev-lang/rust-${PV}
> )"
>
>
> Existing installs should be unaffected ofc.
> But portage may prefer to depclean rust and not rust-bin if both are
> present.
Haven't tested how it reacts, but wouldn't that be an issue with
system-bootstrap in situations where it pulls rust-bin to build itself?
> Users who wish to use source version at all times can just add it to
> world file.
>
> I see both positives and negatives of doing that, but would like to
> reach out to community first.
Unsure what I like best, I generally agree should default to sources
but I do see new users complaining about building rust every few days.
Not that the step of telling them that rust-bin exists is that bad
(part of the issue is that they don't know it's an option).
--
ionen
signature.asc
Description: PGP signature
