[gentoo-dev] Last rites: dev-util/patchbin
# Ionen Wolkens (2022-12-07) # Formerly added to apply binary git patches to wine-staging without git, but # has not been used since 2017 and stuck on EAPI-6. Alternatives: dev-vcs/git # Removal: 2023-01-06. dev-util/patchbin signature.asc Description: PGP signature
[gentoo-dev] Last rites: gstreamer.eclass
commit 9c15f562bf4fb2f33d7e6445e2e8c4133bd95bbb (HEAD -> master, origin/master, origin/HEAD) Author: Sam James Date: Wed Dec 7 17:48:01 2022 + gstreamer.eclass: mark @DEAD for removal No remaining consumers. Removal on 2023-01-07. Signed-off-by: Sam James signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On 07-12-2022 11:52:58 -0500, Mike Gilbert wrote:
> On Wed, Dec 7, 2022 at 4:24 AM James Le Cuirot wrote:
> > The new eclasses also skip the operation if you are root. As that bug report
> > says, running a prefixed system as root is probably unsupported. I was doing
> > this as root into a ROOTed prefix though, which is slightly different.
> > Should
> > we also skip the operation if EPREFIX non-empty? I'll think about it.
>
> I would be in favor of skipping adding users/groups if EPREFIX is
> non-empty, at least as a temporary solution.
>
> If someone presents a use case where adding users to
> ${EROOT}/etc/passwd makes sense, we can revisit it then.
Would have to look if RAP uses this.
@heroxbd do you know if that is used?
Thanks,
Fabian
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On Wed, Dec 7, 2022 at 4:24 AM James Le Cuirot wrote:
> The new eclasses also skip the operation if you are root. As that bug report
> says, running a prefixed system as root is probably unsupported. I was doing
> this as root into a ROOTed prefix though, which is slightly different. Should
> we also skip the operation if EPREFIX non-empty? I'll think about it.
I would be in favor of skipping adding users/groups if EPREFIX is
non-empty, at least as a temporary solution.
If someone presents a use case where adding users to
${EROOT}/etc/passwd makes sense, we can revisit it then.
[gentoo-dev] Last rites: removal of long-masked sys-libs/db slots
# Sam James (2022-12-07) # These versions have been masked for testing since 2014(!). These versions # had a controversial licence change and therefore had limited adoption. # See also the old 2021-05-30-deprecate-old-bdb-slots news item for # additional context. # Removal on 2023-01-07. =sys-libs/db-6.1* =sys-libs/db-6.2* =sys-libs/db-18.1* signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Set CHOST within econf_build to fix config.site
> On 6 Dec 2022, at 21:47, James Le Cuirot wrote: > > On Tue, 2022-12-06 at 10:12 +, Sam James wrote: >> [snip] >> Lgtm provided you've tested it in the relevant envs (which I'm sure you >> have). >> >> Curious how this didn't come up as a problem before, but it >> seems fine! > > econf_build is not widely used, and you only added it to Python in June. It's > been used in other packages for much longer, but Python explicitly checks that > the size of a long is what it expects. I didn't see it with m68k because we > don't have any overrides for that. You also might not see it going from amd64 > to arm64 either with them both being 64-bit. The lack of m68k overrides makes > me wonder if some of these are even needed any more. ac_cv_sizeof_* can > seemingly be determined when cross-compiling now. > > Since we've already had some reports of success, I'm merging this now. Thank you for explaining! That makes sense now. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH 1/4] acct-group.eclass: Fix for when building in a rooted prefix (EROOT)
On Tue, 2022-12-06 at 18:54 -0500, Mike Gilbert wrote:
> On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot wrote:
> >
> > Groups are largely irrelevant for prefix, but we still don't want the
> > build to break.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/acct-group.eclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 590a2f20ed8e..ada5fe386693 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
> > fi
> >
> > if [[ -n ${ROOT} ]]; then
>
> You should probably change this to [[ -n ${EROOT} ]]. Same goes for
> acct-user.eclass.
>
> Also see bug 779181; I'm not sure updating ${EROOT}/etc/group and
> ${EROOT}/etc/passwd makes any sense at all.
Hmm. On closer inspection, and after seeing that bug, I realise I have made
some bad assumptions.
I glanced at my old prefix and saw a bunch of additional users and groups in
there, so I figured the tools must have automatically operated on
${EPREFIX}/etc. In fact, user.eclass skipped the operation if you were root,
and these files were merely copies from /etc. I tried groupadd from a prefix,
and it defaulted to /etc.
The new eclasses also skip the operation if you are root. As that bug report
says, running a prefixed system as root is probably unsupported. I was doing
this as root into a ROOTed prefix though, which is slightly different. Should
we also skip the operation if EPREFIX non-empty? I'll think about it.
Thanks for pointing this out.
signature.asc
Description: This is a digitally signed message part
