Re: [gentoo-user] could there be a problem with acct-group/lp? [RESOLVED]

[n952162]

On 12/30/20 11:17 PM, n952162 wrote:

When I try to restore my pkgs, after the --depclean, the emerge fails.
It seems like there's an error in the pre-inst script of acct-group/lp?
That's need by cups:


1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
 * Package:    acct-group/lp-0-r1
 * Repository: gentoo
 * Maintainer: syst...@gentoo.org print...@gentoo.org
 * USE:    abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
>>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source compiled.
>>> Test phase [not enabled]: acct-group/lp-0-r1

>>> Install acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
>>> Completed installing acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image

 * Final size of build directory:  4 KiB
 * Final size of installed tree:  20 KiB

 * checking 1 files for package collisions
>>> Merging acct-group/lp-0-r1 to /
error writing group entry: Invalid argument
 * Adding group 'lp' to your system ...
error writing group entry: Invalid argument
 *  - Groupid: 7
groupadd: group 'lp' already exists
 * ERROR: acct-group/lp-0-r1::gentoo failed (preinst phase):
 *   (no error message)
 *
 * Call stack:
 * ebuild.sh, line  125:  Called pkg_preinst
 *   environment, line 1194:  Called acct-group_pkg_preinst
 *   environment, line  360:  Called enewgroup 'lp' '7'
 *   environment, line  735:  Called die
 * The specific snippet of code:
 *   groupadd -r ${opts} "${egroup}" || die
 *
 * If you need support, post the output of `emerge --info
'=acct-group/lp-0-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=acct-group/lp-0-r1::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/acct-group/lp-0-r1/homedir'
 * S: '/var/tmp/portage/acct-group/lp-0-r1/work'
!!! FAILED preinst: 1





Confirmed:  I found a mistake on my system:

  lp:x:7:lp:me

The last colon should be a comma.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[n952162]

On 1/1/21 8:47 PM, n952162 wrote:

On 12/31/20 2:14 PM, Michael Orlitzky wrote:

On 12/31/20 2:34 AM, n952162 wrote:


cups was already installed.  I considered removing it, but several
other
things, like ghostscript (!) are dependent on it.  I'm using
--keep-going for now.  I suspect a bug in acct-group/lp that will get
cleared up.



If it's a bug in the acct-user eclass, it's a rare one. It would help
if you could pin down the root cause. It's not something easy like "it
fails if the user already exists." Every user and group ebuild is
already at "-r1", which means they've been reinstalled at least once
on most peoples' machines.



Perhaps this is relevant:

  https://forums.gentoo.org/viewtopic-p-7975642.html

I haven't tried commenting out the group yet because my update is still
in progress...

I'd considering removing the group, like, legally, but was afraid it
might erase things, like my cups ppd files.  But just commenting the
group out is genius.




No, I think I found a mistake on my system:

  lp:x:7:lp:me

The last colon should be a comma.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[n952162]

On 1/1/21 8:47 PM, n952162 wrote:

On 12/31/20 2:14 PM, Michael Orlitzky wrote:

On 12/31/20 2:34 AM, n952162 wrote:


cups was already installed.  I considered removing it, but several
other
things, like ghostscript (!) are dependent on it.  I'm using
--keep-going for now.  I suspect a bug in acct-group/lp that will get
cleared up.



If it's a bug in the acct-user eclass, it's a rare one. It would help
if you could pin down the root cause. It's not something easy like "it
fails if the user already exists." Every user and group ebuild is
already at "-r1", which means they've been reinstalled at least once
on most peoples' machines.



Perhaps this is relevant:

  https://forums.gentoo.org/viewtopic-p-7975642.html

I haven't tried commenting out the group yet because my update is still
in progress...

I'd considering removing the group, like, legally, but was afraid it
might erase things, like my cups ppd files.  But just commenting the
group out is genius.




In particulary, there's this:
https://forums.gentoo.org/viewtopic-p-7975642.html#7975642

Re: [gentoo-user] could there be a problem with acct-group/lp?

[n952162]

On 12/31/20 2:14 PM, Michael Orlitzky wrote:

On 12/31/20 2:34 AM, n952162 wrote:


cups was already installed.  I considered removing it, but several other
things, like ghostscript (!) are dependent on it.  I'm using
--keep-going for now.  I suspect a bug in acct-group/lp that will get
cleared up.



If it's a bug in the acct-user eclass, it's a rare one. It would help
if you could pin down the root cause. It's not something easy like "it
fails if the user already exists." Every user and group ebuild is
already at "-r1", which means they've been reinstalled at least once
on most peoples' machines.



Perhaps this is relevant:

  https://forums.gentoo.org/viewtopic-p-7975642.html

I haven't tried commenting out the group yet because my update is still
in progress...

I'd considering removing the group, like, legally, but was afraid it
might erase things, like my cups ppd files.  But just commenting the
group out is genius.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Michael Orlitzky]

On 12/31/20 2:34 AM, n952162 wrote:


cups was already installed.  I considered removing it, but several other
things, like ghostscript (!) are dependent on it.  I'm using
--keep-going for now.  I suspect a bug in acct-group/lp that will get
cleared up.



If it's a bug in the acct-user eclass, it's a rare one. It would help if 
you could pin down the root cause. It's not something easy like "it 
fails if the user already exists." Every user and group ebuild is 
already at "-r1", which means they've been reinstalled at least once on 
most peoples' machines.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Michael]

On Thursday, 31 December 2020 09:31:13 GMT Neil Bothwick wrote:
> On Thu, 31 Dec 2020 08:34:42 +0100, n952162 wrote:
> > Why do you specify -1?  That's the most common advice I get for avoiding
> > slot-conflicts, but I can't imagine a system without cups.
> 
> To avoid adding to your world file. If a package needs to be in @world,
> it will already be there to -1 will be harmless. In the case of CUPS, you
> don't want it in world as it is a dependency of any program that wants to
> be able to print.

Yes, what Neil sagely advised.  :-)

I suggest you make it a rule to always run emerge for any individual package 
atom with -1, unless you *really* intend to install such a package yourself 
and it has not been already installed as a dependency for other package(s).  
If you do not use -1 the package you emerge will be added in your world file 
and then you could end up fighting against portage sooner or later.

Imagine a hypothetical scenario where one day CUPS is deprecated and replaced 
by the oh-so-marvellous latest and greatest CUPS-ng.  You try to update your 
system, but come up against a blocker because the recently deprecated old CUPS 
now clashes with CUPS-ng.  The old CUPS is in your world file, because you 
added it there by running emerge without -1 and consequently portage cannot 
override your choice and unmerge it to replace it with CUPS-ng.  Portage will 
now throw a wobbly, alerting you to a blocker you must resolve yourself.

This is why you were advised in previous messages related to the recent python 
updates to make sure among other things no python packages have inadvertently 
ended up in your world file.  Unless you're a developer with specific python 
requirements, you would not want python which is both a @system set and 
potentially @world set dependency to end up in there.



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Neil Bothwick]

On Thu, 31 Dec 2020 08:20:22 +0100, n952162 wrote:

> > Is this a new install or reinstall?  All the logic is in the eclass
> > which does have the comment "Creates the group if it does not exist."
> >  
> 
> 
> I was looking for that ... I didn't find groupadd in
> /var/db/pkg/acct-group/lp-0.  Where should I look?

As Jack said, it's in the eclass, $PORTDIR/eclass/acct-group.eclass


-- 
Neil Bothwick

Power corrupts - absolute power is even more fun.


pgpoOQvp1W_Nk.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Neil Bothwick]

On Thu, 31 Dec 2020 08:34:42 +0100, n952162 wrote:

> Why do you specify -1?  That's the most common advice I get for avoiding
> slot-conflicts, but I can't imagine a system without cups.

To avoid adding to your world file. If a package needs to be in @world,
it will already be there to -1 will be harmless. In the case of CUPS, you
don't want it in world as it is a dependency of any program that wants to
be able to print.


-- 
Neil Bothwick

Those who live by the sword get shot by those who don't.


pgpeDzk609B0a.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] could there be a problem with acct-group/lp?

[n952162]

On 12/31/20 1:29 AM, Michael wrote:

On Wednesday, 30 December 2020 23:33:47 GMT Jack wrote:

On 2020.12.30 17:17, n952162 wrote:

When I try to restore my pkgs, after the --depclean, the emerge
fails.
It seems like there's an error in the pre-inst script of
acct-group/lp?
That's need by cups:

1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
  * Package:acct-group/lp-0-r1
  * Repository: gentoo
  * Maintainer: syst...@gentoo.org print...@gentoo.org
  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
  * FEATURES:   network-sandbox preserve-libs sandbox userpriv
usersandbox


Unpacking source...
Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
Source prepared.
Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
Source configured.
Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
Source compiled.
Test phase [not enabled]: acct-group/lp-0-r1

Install acct-group/lp-0-r1 into

/var/tmp/portage/acct-group/lp-0-r1/image


Completed installing acct-group/lp-0-r1 into

/var/tmp/portage/acct-group/lp-0-r1/image

  * Final size of build directory:  4 KiB
  * Final size of installed tree:  20 KiB

  * checking 1 files for package collisions


Merging acct-group/lp-0-r1 to /

error writing group entry: Invalid argument
  * Adding group 'lp' to your system ...
error writing group entry: Invalid argument
  *  - Groupid: 7
groupadd: group 'lp' already exists

This seems to be the basic cause.  However, I have no idea what that
emerge should do if the group it wants to install does already exist.
I can re-emerge this package with no problems.  Is this a new install
or reinstall?  All the logic is in the eclass which does have the
comment "Creates the group if it does not exist."

What happens if you just run "emerge -1 acct-group/lp"?  Have you done
a successful "emerge -auDvN @system" ?  There may well be something
else required still missing, but not an explicit dependency because it
is part of @system.

Some other things to try after @system if the problem persists:

Check the ownership and access rights of /etc/group:

$ stat /etc/group
   File: /etc/group
   Size: 855Blocks: 8  IO Block: 4096   regular file
Device: 80ah/2058d  Inode: 1055521 Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2020-10-25 16:25:42.814894971 +
Modify: 2020-10-25 16:25:42.815894988 +
Change: 2020-10-25 16:25:42.892896366 +
  Birth: 2020-10-25 16:25:42.814894971 +


Check the particular group ID:

$ grep :7: /etc/group
lp:x:7:lp


Emerge cups which installs lp:

emerge -1aDv net-print/cups

Then try again as suggested:

emerge -1aDv acct-group/lp





$ ls -l /etc/group
-rw-r--r-- 1 root root 907 Dec 30 20:53 /etc/group

$ stat  /etc/group
  File: `/etc/group'
  Size: 907 Blocks: 8  IO Block: 4096 regular file
Device: 801h/2049d  Inode: 950897  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: ( 0/    root)
Access: 2020-12-30 20:53:13.0 +0100
Modify: 2020-12-30 20:53:12.0 +0100
Change: 2020-12-30 20:53:12.0 +0100
 Birth: -
$ grep :7: /etc/group
lp:x:7:lp:me


cups was already installed.  I considered removing it, but several other
things, like ghostscript (!) are dependent on it.  I'm using
--keep-going for now.  I suspect a bug in acct-group/lp that will get
cleared up.


Why do you specify -1?  That's the most common advice I get for avoiding
slot-conflicts, but I can't imagine a system without cups.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[n952162]

On 12/31/20 12:33 AM, Jack wrote:

On 2020.12.30 17:17, n952162 wrote:

When I try to restore my pkgs, after the --depclean, the emerge fails.
It seems like there's an error in the pre-inst script of acct-group/lp?
That's need by cups:

1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
 * Package:    acct-group/lp-0-r1
 * Repository: gentoo
 * Maintainer: syst...@gentoo.org print...@gentoo.org
 * USE:    abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv
usersandbox
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
>>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source compiled.
>>> Test phase [not enabled]: acct-group/lp-0-r1

>>> Install acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
>>> Completed installing acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image

 * Final size of build directory:  4 KiB
 * Final size of installed tree:  20 KiB

 * checking 1 files for package collisions
>>> Merging acct-group/lp-0-r1 to /
error writing group entry: Invalid argument
 * Adding group 'lp' to your system ...
error writing group entry: Invalid argument
 *  - Groupid: 7
groupadd: group 'lp' already exists

This seems to be the basic cause.



Perhaps.  But there are two "invalid argument" error messages before the
"already exists" msg.



However, I have no idea what that emerge should do if the group it
wants to install does already exist.  I can re-emerge this package
with no problems.



That's interesting!  Maybe re-emerge would behave differently from a
de-install/emerge?

In any case though, crashing if the group already exists would be a bug
the developers should be interested in.



Is this a new install or reinstall?  All the logic is in the eclass
which does have the comment "Creates the group if it does not exist."



I was looking for that ... I didn't find groupadd in
/var/db/pkg/acct-group/lp-0.  Where should I look?




What happens if you just run "emerge -1 acct-group/lp"?



Same thing



Have you done a successful "emerge -auDvN @system" ?



Yes



There may well be something else required still missing, but not an
explicit dependency because it is part of @system.




One thing I just re-discovered is --keep-going, which works, thank
goodness, so I'll should have a working system (sometime tomorrow!),
albeit, without cups.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Michael]

On Wednesday, 30 December 2020 23:33:47 GMT Jack wrote:
> On 2020.12.30 17:17, n952162 wrote:
> > When I try to restore my pkgs, after the --depclean, the emerge
> > fails. 
> > It seems like there's an error in the pre-inst script of
> > acct-group/lp? 
> > That's need by cups:
> > 
> > 1270~/adm/gentoo/emerged>sudo cat
> > /var/tmp/portage/acct-group/lp-0-r1/temp/build.log
> >  * Package:acct-group/lp-0-r1
> >  * Repository: gentoo
> >  * Maintainer: syst...@gentoo.org print...@gentoo.org
> >  * USE:abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
> >  * FEATURES:   network-sandbox preserve-libs sandbox userpriv
> > usersandbox
> > 
> > >>> Unpacking source...
> > >>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
> > >>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
> > >>> Source prepared.
> > >>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
> > >>> Source configured.
> > >>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
> > >>> Source compiled.
> > >>> Test phase [not enabled]: acct-group/lp-0-r1
> > >>> 
> > >>> Install acct-group/lp-0-r1 into
> > 
> > /var/tmp/portage/acct-group/lp-0-r1/image
> > 
> > >>> Completed installing acct-group/lp-0-r1 into
> > 
> > /var/tmp/portage/acct-group/lp-0-r1/image
> > 
> >  * Final size of build directory:  4 KiB
> >  * Final size of installed tree:  20 KiB
> > 
> >  * checking 1 files for package collisions
> > 
> > >>> Merging acct-group/lp-0-r1 to /
> > 
> > error writing group entry: Invalid argument
> >  * Adding group 'lp' to your system ...
> > error writing group entry: Invalid argument
> >  *  - Groupid: 7
> > groupadd: group 'lp' already exists
> 
> This seems to be the basic cause.  However, I have no idea what that
> emerge should do if the group it wants to install does already exist.
> I can re-emerge this package with no problems.  Is this a new install
> or reinstall?  All the logic is in the eclass which does have the
> comment "Creates the group if it does not exist."
> 
> What happens if you just run "emerge -1 acct-group/lp"?  Have you done
> a successful "emerge -auDvN @system" ?  There may well be something
> else required still missing, but not an explicit dependency because it
> is part of @system.

Some other things to try after @system if the problem persists:

Check the ownership and access rights of /etc/group:

$ stat /etc/group
  File: /etc/group
  Size: 855 Blocks: 8  IO Block: 4096   regular file
Device: 80ah/2058d  Inode: 1055521 Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2020-10-25 16:25:42.814894971 +
Modify: 2020-10-25 16:25:42.815894988 +
Change: 2020-10-25 16:25:42.892896366 +
 Birth: 2020-10-25 16:25:42.814894971 +


Check the particular group ID:

$ grep :7: /etc/group
lp:x:7:lp


Emerge cups which installs lp:

emerge -1aDv net-print/cups

Then try again as suggested:

emerge -1aDv acct-group/lp






signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] could there be a problem with acct-group/lp?

[Jack]

On 2020.12.30 17:17, n952162 wrote:
When I try to restore my pkgs, after the --depclean, the emerge  
fails. 
It seems like there's an error in the pre-inst script of  
acct-group/lp? 

That's need by cups:

1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
 * Package:    acct-group/lp-0-r1
 * Repository: gentoo
 * Maintainer: syst...@gentoo.org print...@gentoo.org
 * USE:    abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv  
usersandbox

>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
>>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source compiled.
>>> Test phase [not enabled]: acct-group/lp-0-r1

>>> Install acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
>>> Completed installing acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image

 * Final size of build directory:  4 KiB
 * Final size of installed tree:  20 KiB

 * checking 1 files for package collisions
>>> Merging acct-group/lp-0-r1 to /
error writing group entry: Invalid argument
 * Adding group 'lp' to your system ...
error writing group entry: Invalid argument
 *  - Groupid: 7
groupadd: group 'lp' already exists
This seems to be the basic cause.  However, I have no idea what that  
emerge should do if the group it wants to install does already exist.   
I can re-emerge this package with no problems.  Is this a new install  
or reinstall?  All the logic is in the eclass which does have the  
comment "Creates the group if it does not exist."


What happens if you just run "emerge -1 acct-group/lp"?  Have you done  
a successful "emerge -auDvN @system" ?  There may well be something  
else required still missing, but not an explicit dependency because it  
is part of @system.



 * ERROR: acct-group/lp-0-r1::gentoo failed (preinst phase):
 *   (no error message)
 *
 * Call stack:
 * ebuild.sh, line  125:  Called pkg_preinst
 *   environment, line 1194:  Called acct-group_pkg_preinst
 *   environment, line  360:  Called enewgroup 'lp' '7'
 *   environment, line  735:  Called die
 * The specific snippet of code:
 *   groupadd -r ${opts} "${egroup}" || die
 *
 * If you need support, post the output of `emerge --info
'=acct-group/lp-0-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=acct-group/lp-0-r1::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/acct-group/lp-0-r1/homedir'
 * S: '/var/tmp/portage/acct-group/lp-0-r1/work'
!!! FAILED preinst: 1

Then there's this, from emerge --info:

Password:
Portage 3.0.9 (python 3.8.6-final-0, default/linux/amd64/17.1,
gcc-9.3.0, glibc-2.32-r3, 4.19.72-gentoo x86_64)
=
 System Settings
=
System uname:
Linux-4.19.72-gentoo-x86_64-AMD_A9-9420_RADEON_R5,_5_COMPUTE_CORES_2C+3G-with-glibc2.2.5
KiB Mem: 7672120 total,   1147028 free
KiB Swap:    8388604 total,   8387316 free
Timestamp of repository gentoo: Wed, 30 Dec 2020 20:30:01 +
Head commit of repository gentoo:  
19c597e94d94dff08de5c0d8a692f871b75c4130

sh bash 5.0_p18
ld GNU ld (Gentoo 2.34 p6) 2.34.0
app-shells/bash:  5.0_p18::gentoo
dev-lang/perl:    5.30.3::gentoo
dev-lang/python:  2.7.18-r4::gentoo, 3.6.12::gentoo,
3.7.9::gentoo, 3.8.6::gentoo, 3.9.0::gentoo
dev-util/cmake:   3.17.4-r1::gentoo
sys-apps/baselayout:  2.7::gentoo
sys-apps/openrc:  0.42.1::gentoo
sys-apps/sandbox: 2.20::gentoo
sys-devel/autoconf:   2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:   1.16.2-r1::gentoo
sys-devel/binutils:   2.34-r2::gentoo
sys-devel/gcc:    9.3.0-r2::gentoo
sys-devel/gcc-config: 2.3.2-r1::gentoo
sys-devel/libtool:    2.4.6-r6::gentoo
sys-devel/make:   4.3::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc:   2.32-r3::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24
    sync-rsync-extra-opts:
    sync-rsync-verify-metamanifest: yes

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf