Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 821556 - libxcrypt dependency chain failure/bug
Summary: libxcrypt dependency chain failure/bug
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-04 00:20 UTC by brankob
Modified: 2021-11-04 00:47 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info output (my_emerge.info,7.07 KB, text/plain)
2021-11-04 00:20 UTC, brankob
Details

Note You need to log in before you can comment on or make changes to this bug.
Description brankob 2021-11-04 00:20:17 UTC
Created attachment 748368 [details]
emerge --info output

I've updated the system, which requered me to add sys-libs/libxcrypt into the tree.

I did it, but now every update @world attempt fails with:

"emerge: there are no ebuilds to satisfy "sys-libs/libxcrypt[system(-),static-libs(-)?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]".
(dependency required by "virtual/libcrypt-2::gentoo" [ebuild])
(dependency required by "@__auto_slot_operator_replace_installed__" [argument])"

I am used to portage encryption of this kind, but this still baffles me.
It appears that it complains that it can't emerge libxcrypt with flags that it obviously can emerge libxcrypt with. I also don't udnderstand why all the ABIs are disabled with it.

"emerge -1 libxcrypt" works just fine and does this:

"sys-libs/libxcrypt-4.4.26:0/1::gentoo  USE=compat (-split-usr) -static-libs (-system) -test" ABI_X86="32 (64) (-x32)"

But any attempt to emerge libcrypt or @world fails with aforementioned error message.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-04 00:26:54 UTC
(In reply to Branko Badrljica from comment #0)
> Created attachment 748368 [details]
> emerge --info output
> 
> I've updated the system, which requered me to add sys-libs/libxcrypt into
> the tree.

What does "add... into the tree" mean?

> 
> I did it, but now every update @world attempt fails with:
> 
> "emerge: there are no ebuilds to satisfy
> "sys-libs/libxcrypt[system(-),static-libs(-)?,abi_x86_32(-)?,abi_x86_64(-)?,
> abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
> abi_s390_32(-)?,abi_s390_64(-)?]".
> (dependency required by "virtual/libcrypt-2::gentoo" [ebuild])
> (dependency required by "@__auto_slot_operator_replace_installed__"
> [argument])"
> 
> I am used to portage encryption of this kind, but this still baffles me.
> It appears that it complains that it can't emerge libxcrypt with flags that
> it obviously can emerge libxcrypt with. I also don't udnderstand why all the
> ABIs are disabled with it.
> 
> "emerge -1 libxcrypt" works just fine and does this:
> 
> "sys-libs/libxcrypt-4.4.26:0/1::gentoo  USE=compat (-split-usr) -static-libs
> (-system) -test" ABI_X86="32 (64) (-x32)"

"(-system)" means that the system flag is masked. This shouldn't be happening as the profiles include it being on.

This MIGHT be related to the top line from your emerge --info output:
>Portage 3.0.28 (python 3.9.7-final-0, !../../var/db/my_gentoo/profiles/default/linux/amd64/17.1/hardened/selinux, gcc-11.2.0, glibc-2.33-r7, 5.14.15-gentoo x86_64)

... your profile symlink is broken? Can you fix it?

Can you also run:
grep -rsin "libxcrypt" /etc/portage

> 
> But any attempt to emerge libcrypt or @world fails with aforementioned error
> message.

Please do include the full command and output. Try running: emerge -p -uvDU @world.
Comment 2 brankob 2021-11-04 00:43:16 UTC
No need. 
Fixing the profile link seems to have fixed it.
I wonder what else might be broken.
Time to reemerge the system.
Comment 3 brankob 2021-11-04 00:44:29 UTC
BTW, Thanks.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-04 00:47:01 UTC
(In reply to Branko Badrljica from comment #3)
> BTW, Thanks.

No problem! :)