Bug 904474 – keyword request ~arm64-macos for prefix bootstrap packages

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Andrey Aleksandrov 2023-04-17 14:51:17 UTC]

I did full gentoo prefix bootstrap with new ~arm64-macos prefix on MacOS with M1. This is list of packages that portage failed to install because packages have ~x64-macos keyword, but don't have ~arm64-macos keyword.

acct-group/man
acct-user/man
app-admin/perl-cleaner
app-arch/unzip
app-arch/zstd
app-crypt/gnupg
app-crypt/gpgme
app-crypt/libb2
app-crypt/pinentry
app-editors/nano
app-eselect/eselect-lib-bin-symlink
app-eselect/eselect-pinentry
app-misc/ca-certificates
app-misc/editor-wrapper
app-misc/getopt
app-misc/pax-utils
app-portage/elt-patches
app-portage/portage-utils
app-text/build-docbook-catalog
app-text/docbook-xml-dtd
app-text/docbook-xsl-stylesheets
app-text/manpager
app-text/opensp
app-text/po4a
app-text/sgml-common
dev-db/sqlite
dev-lang/perl
dev-lang/python-exec
dev-lang/python-exec-conf
dev-lang/tcl
dev-libs/expat
dev-libs/gmp
dev-libs/libassuan
dev-libs/libffi
dev-libs/libgcrypt
dev-libs/libgpg-error
dev-libs/libksba
dev-libs/libltdl
dev-libs/libpipeline
dev-libs/libtasn1
dev-libs/libunistring
dev-libs/libxml2
dev-libs/libxslt
dev-libs/mpc
dev-libs/mpfr
dev-libs/nettle
dev-libs/npth
dev-libs/openssl
dev-libs/popt
dev-perl/ExtUtils-CChecker
dev-perl/Locale-gettext
dev-perl/MIME-Charset
dev-perl/Module-Build
dev-perl/Pod-Parser
dev-perl/SGMLSpm
dev-perl/Syntax-Keyword-Try
dev-perl/TermReadKey
dev-perl/Text-CharWidth
dev-perl/Text-WrapI18N
dev-perl/Unicode-LineBreak
dev-perl/XS-Parse-Keyword
dev-perl/YAML-Tiny
dev-python/certifi
dev-python/cython
dev-python/flit_core
dev-python/gpep517
dev-python/inflect
dev-python/installer
dev-python/jaraco-context
dev-python/jaraco-functools
dev-python/more-itertools
dev-python/nspektr
dev-python/ordered-set
dev-python/packaging
dev-python/pyparsing
dev-python/setuptools-scm
dev-python/tomli
dev-python/typing-extensions
dev-python/wheel
dev-util/gtk-doc-am
dev-util/meson
dev-util/meson-format-array
dev-util/ninja
dev-util/re2c
net-dns/c-ares
net-dns/libidn2
net-libs/gnutls
net-misc/curl
perl-core/File-Temp
sys-apps/baselayout
sys-apps/darwin-miscutils
sys-apps/gentoo-functions
sys-apps/man-db
sys-apps/texinfo
sys-apps/util-linux
sys-apps/which
sys-devel/autoconf
sys-devel/autoconf-archive
sys-devel/autoconf-wrapper
sys-devel/automake
sys-devel/automake-wrapper
sys-devel/bison
sys-devel/flex
sys-devel/gcc-config
sys-devel/libtool
sys-devel/m4
sys-devel/native-cctools
sys-libs/gdbm
sys-libs/ncurses
sys-libs/zlib
sys-process/pkill-darwin
virtual/libcrypt
virtual/perl-CPAN
virtual/perl-CPAN-Meta
virtual/perl-CPAN-Meta-YAML
virtual/perl-Carp
virtual/perl-Data-Dumper
virtual/perl-Encode
virtual/perl-Exporter
virtual/perl-ExtUtils-CBuilder
virtual/perl-ExtUtils-Install
virtual/perl-ExtUtils-MakeMaker
virtual/perl-ExtUtils-Manifest
virtual/perl-ExtUtils-ParseXS
virtual/perl-File-Spec
virtual/perl-File-Temp
virtual/perl-Getopt-Long
virtual/perl-JSON-PP
virtual/perl-Module-Metadata
virtual/perl-Parse-CPAN-Meta
virtual/perl-Perl-OSType
virtual/perl-Scalar-List-Utils
virtual/perl-Test-Harness
virtual/perl-Text-ParseWords
virtual/perl-podlators
virtual/perl-version
virtual/tmpfiles

[addCollapseLink(1, 1, 'Toggle comment display'); Comment 1 NATTkA bot 2023-04-18 15:48:13 UTC Comment hidden (obsolete)]

Unable to check for sanity:

> package masked: dev-python/cython-3.0.0_beta2

[Comment 2 Sam James 2023-04-22 11:43:37 UTC]

I assume this means you've tested all of these?

[Comment 3 Sam James 2023-04-22 11:57:17 UTC]

I think we can assume all of these things work well enough if a successful bootstrap was made before.

[Comment 4 Larry the Git Cow 2023-04-22 12:08:11 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=8db9b4cf4a1f931e5d371fafe588eb28ccea1a60

commit 8db9b4cf4a1f931e5d371fafe588eb28ccea1a60
Author:     Sam James <[e-mail]>
AuthorDate: 2023-04-22 12:07:55 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-22 12:07:55 +0000

    sys-devel/gcc-config: keyword ~x64-macos
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Sam James <[e-mail]>

 sys-devel/gcc-config/gcc-config-1.9.1.ebuild  | 2 +-
 sys-devel/gcc-config/gcc-config-2.7-r1.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

[Comment 5 Sam James 2023-04-22 12:09:07 UTC]

Pushed with:

remote: Resolving deltas: 100% (708/708), completed with 335 local objects.
remote:  * Info: Using [Gentoo] (https://bugs.gentoo.org/xmlrpc.cgi)
remote:  # Error: Bugzilla error: Comments cannot be longer than 16384 characters. If you need to post contents of files or logs, use the attachment feature instead.
remote: remote: Resolving deltas: 100% (717/717), completed with 335 local objects.
remote: To github.com:gentoo/gentoo.git
remote:    e9dd196e50cf..96b6dba5f4f5  master -> master
remote: To gitlab.gentoo.org:gentoo/gentoo.git
remote:    e9dd196e50cf..96b6dba5f4f5  master -> master
To git+ssh://git.gentoo.org/repo/gentoo.git
   e9dd196e50cf..96b6dba5f4f5  master -> master

... so no automatic bugzilla comments for them.

If there's any other *critical* stuff, we can reuse this bug, but otherwise, let's file new ones.

[Comment 6 NATTkA bot 2023-04-22 12:12:41 UTC]

All sanity-check issues have been resolved

[Comment 7 Tom Li 2023-04-22 12:19:55 UTC]

(In reply to Tom Li from comment #25 from Bug #886491)
> > I'm seriously
> > dissatisfied with the decision to split "~arm64-macos" from "~x64-macos".
> > What problem is it supposed it solve?

> Marking something as working when it definitely doesn't? That's what our 
> keywording system is for.
> It solves the problem of things like b2 and flex being tagged as "working"
> when they didn't.

Both b2 and flex are runtime failures due to software bugs. They can be built without any obvious signs of problems. In fact I've successfully completed a bootstrap with a broken flex. Until I later tried to build something that actually invokes flex.

I agree that "~arm64-macos" should eventually have its separate test just for the sake of technical consistency, but I'm sure really sure about its utility at this moment.

(In reply to Sam James from comment #3)
> I think we can assume all of these things work well enough if a successful
> bootstrap was made before.

Based on this criteria, both b2 and flex would escape detection and be deemed to be "work well enough". This would bring us back to the point that we began when ""~x64-macos" and "~arm64-macos" were treated as the same architecture, and it would not have prevented the problems that I discovered.

Alternatively, if the bar is set higher and a package needs to be truly functional, it would be extremely difficult for anyone to say anything about whether a package functional. How would you know if all the C APIs found in dev-libs/libgcrypt, dev-libs/libxml2, or sys-libs/zlib are truly functional and does not cause a crash?

How should the standard be set? How was this issue handled historically by Gentoo Prefix?

[Comment 8 Sam James 2023-04-23 06:45:49 UTC]

(In reply to Tom Li from comment #7)
> (In reply to Tom Li from comment #25 from Bug #886491)
> > > I'm seriously
> > > dissatisfied with the decision to split "~arm64-macos" from "~x64-macos".
> > > What problem is it supposed it solve?
> 
> > Marking something as working when it definitely doesn't? That's what our 
> > keywording system is for.
> > It solves the problem of things like b2 and flex being tagged as "working"
> > when they didn't.
> 
> Both b2 and flex are runtime failures due to software bugs. They can be
> built without any obvious signs of problems. In fact I've successfully
> completed a bootstrap with a broken flex. Until I later tried to build
> something that actually invokes flex.
> 
> I agree that "~arm64-macos" should eventually have its separate test just
> for the sake of technical consistency, but I'm sure really sure about its
> utility at this moment.
> 
> (In reply to Sam James from comment #3)
> > I think we can assume all of these things work well enough if a successful
> > bootstrap was made before.
> 
> Based on this criteria, both b2 and flex would escape detection and be
> deemed to be "work well enough". This would bring us back to the point that
> we began when ""~x64-macos" and "~arm64-macos" were treated as the same
> architecture, and it would not have prevented the problems that I discovered.
> 

We wouldn't have keyworded flex because it couldn't bootstrap a Prefix. And b2 couldn't build Boost.

> Alternatively, if the bar is set higher and a package needs to be truly
> functional, it would be extremely difficult for anyone to say anything about
> whether a package functional. How would you know if all the C APIs found in
> dev-libs/libgcrypt, dev-libs/libxml2, or sys-libs/zlib are truly functional
> and does not cause a crash?
> 

We run their test suites ("ebuild ... clean test install", or FEATURES=test emerge ...) and sometimes check reverse dependencies and their test suites too. Of course, if someone reports a problem, or we are otherwise made aware of an issue, that counts too.

This is how keywording and stabilisation work in general in Gentoo.

> How should the standard be set? How was this issue handled historically by
> Gentoo Prefix?

The standard is what I've said above, although is sometimes a bit more lax on prefix given it's a lot of work to keyword all recursive test dependencies.

What we could have done (and could possibly still do) is propagate all existing ~x64-macos -> ~arm64-macos at least (could also filter out some stuff by eye which looks suspicious/not critical), but I'm not sure that's worthwhile.

[Comment 9 Tom Li 2023-04-23 07:07:00 UTC]

(In reply to Sam James from comment #8)
> We run their test suites ("ebuild ... clean test install", or FEATURES=test
> emerge ...) and sometimes check reverse dependencies and their test suites
> too. Of course, if someone reports a problem, or we are otherwise made aware
> of an issue, that counts too.
> 
> This is how keywording and stabilisation work in general in Gentoo.

Fair enough.

[Comment 10 Tom Li 2023-04-23 07:18:53 UTC]

I just tried bootstrapping with portage-20230421.tar.gz, unfortunately the changes committed into the tree yesterday were still not being picked up. There is also no instruction on the correct method to create a fresh prefix portage, and the only option would be studying the script update-rsync-master. It deserves some documentation.

I'll wait a few days before trying again. I'll report back if I can confirm that the latest snapshot is bootstrappable. At that time, this bug report can be closed.

[Comment 11 Fabian Groffen 2023-04-23 07:31:03 UTC]

you used LATEST_TREE_YES I presume?

[Comment 12 Fabian Groffen 2023-04-23 07:32:59 UTC]

By the way latest is portage-20230422.tar.xz, the date is slightly confusing as it creates the snapshot at 3am Europe/Amsterdam time.  So it basically includes everything from the day before.

[Comment 13 Sam James 2023-04-23 07:35:53 UTC]

can also set TREE_FROM_SRC=1

[Comment 14 Tom Li 2023-04-23 07:56:09 UTC]

(In reply to Fabian Groffen from comment #12)
> By the way latest is portage-20230422.tar.xz, the date is slightly confusing
> as it creates the snapshot at 3am Europe/Amsterdam time.  So it basically
> includes everything from the day before.

This file still has not appeared at https://rsync.prefix.bitzolder.nl/snapshots/ yet.

[Comment 15 Sam James 2023-04-23 07:57:17 UTC]

(In reply to Tom Li from comment #14)
> (In reply to Fabian Groffen from comment #12)
> > By the way latest is portage-20230422.tar.xz, the date is slightly confusing
> > as it creates the snapshot at 3am Europe/Amsterdam time.  So it basically
> > includes everything from the day before.
> 
> This file still has not appeared at
> https://rsync.prefix.bitzolder.nl/snapshots/ yet.

I see https://rsync.prefix.bitzolder.nl/snapshots/portage-20230422.tar.gz.

[Comment 16 Tom Li 2023-04-23 08:02:24 UTC]

(In reply to Sam James from comment #15)
> (In reply to Tom Li from comment #14)
> > (In reply to Fabian Groffen from comment #12)
> > > By the way latest is portage-20230422.tar.xz, the date is slightly confusing
> > > as it creates the snapshot at 3am Europe/Amsterdam time.  So it basically
> > > includes everything from the day before.
> > 
> > This file still has not appeared at
> > https://rsync.prefix.bitzolder.nl/snapshots/ yet.
> 
> I see https://rsync.prefix.bitzolder.nl/snapshots/portage-20230422.tar.gz.

I see 404 Not Found.

I also believed that I saw the file portage-20230422.tar.gz just once, before I started trying today's bootstrap. However, the server ended up getting portage-20230421 instead. I also fail to see this file on my current computer.

A mirroring issue?

[Comment 17 Fabian Groffen 2023-04-23 08:17:07 UTC]

you're right, try https://rsync1.prefix.bitzolder.nl/snapshots/

I'll look into why rsync2 appears to be behind

[Comment 18 Tom Li 2023-04-23 19:17:50 UTC]

There are still several keyword bugs.

First, acct-user/man and acct-group/man still need the ~arm64-macos keyword. It should be added to the eclass files acct-user.eclass and acct-group.eclass.

Next, app-eselect/eselect-lib-bin-symlink-9999 should NOT be keyworded with ~arm64-macos. Yesterday's change was incorrect. Instead, the the ebuild eselect-lib-bin-symlink-0.1.1-r1 should've received the keyword. Please remove the ~arm64-macos keyword from the 9999 package and add it to the stable package instead. It's usually wrong to give a keyword to any 9999 package, not to mention that during stage3 bootstrapping, git is unavailable, keywording the 9999 ebuild causes bootstrap to fail due to missing git.

!!! All ebuilds that could satisfy ">=dev-vcs/git-1.8.2.1[curl]" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-vcs/git-9999-r3::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-9999-r2::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-9999-r1::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-9999::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-2.40.0::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-2.39.2::gentoo_prefix (masked by: missing keyword)
- dev-vcs/git-2.39.1::gentoo_prefix (masked by: missing keyword)

(dependency required by "app-eselect/eselect-lib-bin-symlink-9999::gentoo_prefix" [ebuild])
(dependency required by "app-eselect/eselect-pinentry-0.7.2-r1::gentoo_prefix" [ebuild])
(dependency required by "app-crypt/pinentry-1.2.1-r1::gentoo_prefix" [ebuild])
(dependency required by "app-crypt/gnupg-2.4.0::gentoo_prefix" [ebuild])
(dependency required by "app-crypt/gpgme-1.20.0::gentoo_prefix" [ebuild])
(dependency required by "app-portage/portage-utils-0.95::gentoo_prefix[-static,qmanifest]" [ebuild])
(dependency required by "app-admin/perl-cleaner-2.30-r1::gentoo_prefix[-pkgcore]" [installed])
(dependency required by "dev-lang/perl-5.36.0-r2::gentoo_prefix[-minimal]" [ebuild])
(dependency required by "dev-libs/openssl-3.0.8-r4::gentoo_prefix" [installed])
(dependency required by "dev-lang/python-3.10.4::gentoo_prefix[ssl]" [ebuild])
(dependency required by "dev-util/meson-1.1.0::gentoo_prefix[python_targets_python3_10]" [installed])
(dependency required by "app-arch/zstd-1.5.5::gentoo_prefix" [installed])
(dependency required by "sys-apps/portage-3.0.34.2::gentoo_prefix" [installed])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

[Comment 19 Sam James 2023-04-23 19:21:24 UTC]

(In reply to Tom Li from comment #18)
> There are still several keyword bugs.
> 
> First, acct-user/man and acct-group/man still need the ~arm64-macos keyword.
> It should be added to the eclass files acct-user.eclass and
> acct-group.eclass.

I'll do that now.

> 
> Next, app-eselect/eselect-lib-bin-symlink-9999 should NOT be keyworded with
> ~arm64-macos. Yesterday's change was incorrect. Instead, the the ebuild
> eselect-lib-bin-symlink-0.1.1-r1 should've received the keyword. Please
> remove the ~arm64-macos keyword from the 9999 package and add it to the
> stable package instead. It's usually wrong to give a keyword to any 9999
> package, not to mention that during stage3 bootstrapping, git is
> unavailable, keywording the 9999 ebuild causes bootstrap to fail due to
> missing git.

We shouldn't really allow live ebuilds without a template, ugh. I did try to spot these but apparently missed this one. I'll check for others now.

[Comment 20 Sam James 2023-04-23 19:24:24 UTC]

(In reply to Sam James from comment #19)
> (In reply to Tom Li from comment #18)
> > There are still several keyword bugs.
> > 
> > First, acct-user/man and acct-group/man still need the ~arm64-macos keyword.
> > It should be added to the eclass files acct-user.eclass and
> > acct-group.eclass.
> 
> I'll do that now.
> 
> > 
> > Next, app-eselect/eselect-lib-bin-symlink-9999 should NOT be keyworded with
> > ~arm64-macos. Yesterday's change was incorrect. Instead, the the ebuild
> > eselect-lib-bin-symlink-0.1.1-r1 should've received the keyword. Please
> > remove the ~arm64-macos keyword from the 9999 package and add it to the
> > stable package instead. It's usually wrong to give a keyword to any 9999
> > package, not to mention that during stage3 bootstrapping, git is
> > unavailable, keywording the 9999 ebuild causes bootstrap to fail due to
> > missing git.
> 
> We shouldn't really allow live ebuilds without a template, ugh. I did try to
> spot these but apparently missed this one. I'll check for others now.

pkgcheck scan -k VisibleVcsPkg -a arm64-macos gives no other results.

[Comment 21 Larry the Git Cow 2023-04-23 19:25:13 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6c334e881954362dfb3380b237a962198d6be947

commit 6c334e881954362dfb3380b237a962198d6be947
Author:     Sam James <[e-mail]>
AuthorDate: 2023-04-23 19:22:37 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-23 19:22:37 +0000

    acct-user.eclass: add ~arm64-macos to KEYWORDS
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Sam James <[e-mail]>

 eclass/acct-user.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e348fabe98f4ec373193b784c4a113e7f95ad713

commit e348fabe98f4ec373193b784c4a113e7f95ad713
Author:     Sam James <[e-mail]>
AuthorDate: 2023-04-23 19:22:26 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-23 19:22:26 +0000

    acct-group.eclass: add ~arm64-macos to KEYWORDS
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Sam James <[e-mail]>

 eclass/acct-group.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d89bbcf64981ef1278b8df81aae55d705df1eccb

commit d89bbcf64981ef1278b8df81aae55d705df1eccb
Author:     Sam James <[e-mail]>
AuthorDate: 2023-04-23 19:20:36 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-23 19:20:36 +0000

    app-eselect/eselect-lib-bin-symlink: unkeyword 9999 for ~arm64-macos
    
    Bug: https://bugs.gentoo.org/904474
    Fixes: 4d55cae162bfb3da0982dd859a6f4cb56716ad12
    Signed-off-by: Sam James <[e-mail]>

 app-eselect/eselect-lib-bin-symlink/eselect-lib-bin-symlink-9999.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Comment 22 Sam James 2023-04-23 19:25:32 UTC]

(Ultimately, bugs like that wrt visibility will be way more noticeable if we can get arm64-macos + x64-macos into a state where CI is run on them because the depgraph is clean.)

[Comment 23 Tom Li 2023-04-23 19:34:57 UTC]

The current status of ~arm64-macos is pretty problematic in my opinion - right now it has a lower "stability" status than ~ppc-macos - I doubt these classic PPC Macintosh machines are still routinely used and tested today, yet a huge portion of the portage tree is filled with packages keyworded with ~ppc-macos, but not ~arm64-macos.

To be fair, a lot packages appear to be Perl or Python libraries, which is reasonable to assume portability, tagging these packages with unstable keywords is very understandable. But if it's the case, ~arm64-macos should receive a similar treatment.

[Comment 24 Sam James 2023-04-23 19:38:16 UTC]

(In reply to Tom Li from comment #23)
> The current status of ~arm64-macos is pretty problematic in my opinion -
> right now it has a lower "stability" status than ~ppc-macos - I doubt these
> classic PPC Macintosh machines are still routinely used and tested today,
> yet a huge portion of the portage tree is filled with packages keyworded
> with ~ppc-macos, but not ~arm64-macos.
> 
> To be fair, a lot packages appear to be Perl or Python libraries, which is
> reasonable to assume portability, tagging these packages with unstable
> keywords is very understandable. But if it's the case, ~arm64-macos should
> receive a similar treatment.

I can't speak for ppc-macos but a lot of these are either ALLARCHES (see metadata.xml, the '<stabilize-allarches/>' tag - which is a good sign that something is arch independent, or for Perl at least, stuff which doesn't get releases anymore).

I did offer yesterday to look at propagating ~x64-macos -> ~arm64-macos with some manual review of the list to exclude anything which looks a bit dubious. I could at least do that for ALLARCHES packages, with a manual pass to check the list looks sensible, too.

But also, this is kind of just how porting a new platform is. You end up testing lots of stuff.

[Comment 25 Tom Li 2023-04-23 19:52:52 UTC]

I found more problems. dev-libs/libgcrypt wants to use Linux's getrandom() system call on macOS, and obviously it doesn't work. For some reason, it didn't find the proper fallback implementation during ./configure. Please remove all macOS keywords from libgcrypt's 1.10 branch until the problem is investigated, including libgcrypt-1.10.1-r2, libgcrypt-1.10.1-r3, and libgcrypt-1.10.1-r2.

/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/random/rndgetentropy.c:98:21: warning: implicit declaration of function 'getrandom'; did you mean 'srandom'? [-Wimplicit-function-declaration]
   98 |               ret = getrandom (buffer, nbytes, GRND_RANDOM);
      |                     ^~~~~~~~~
      |                     srandom
/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/random/rndgetentropy.c:98:48: error: 'GRND_RANDOM' undeclared (first use in this function)
   98 |               ret = getrandom (buffer, nbytes, GRND_RANDOM);
      |                                                ^~~~~~~~~~~
/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/random/rndgetentropy.c:98:48: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [Makefile:514: rndgetentropy.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2-.arm64/random'
make[1]: *** [Makefile:504: all-recursive] Error 1
make[1]: Leaving directory '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2-.arm64'
make: *** [Makefile:436: all] Error 2
 * ERROR: dev-libs/libgcrypt-1.10.2::gentoo_prefix failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/libgcrypt-1.10.2::gentoo_prefix'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/libgcrypt-1.10.2::gentoo_prefix'`.
 * The complete build log is located at '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/temp/build.log'.
 * The ebuild environment file is located at '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/temp/environment'.
 * Working directory: '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2-.arm64'
 * S: '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2'

>>> Failed to emerge dev-libs/libgcrypt-1.10.2, Log file:
>>>  '/Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/temp/build.log'

[Comment 26 Sam James 2023-04-23 19:55:10 UTC]

I've got 1.10.1-r1 built OK on x86-macos so I'll keep x64-macos KEYWORDS for now.

[Comment 27 Larry the Git Cow 2023-04-23 19:55:38 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68b215f2345c995a688ea630eab5f58c3d77c2b7

commit 68b215f2345c995a688ea630eab5f58c3d77c2b7
Author:     Sam James <[e-mail]>
AuthorDate: 2023-04-23 19:53:53 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-23 19:53:53 +0000

    dev-libs/libgcrypt: drop ~arm64-macos for 1.10.*
    
    From Tom Li on the linked bug:
    ```
    /Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/random/rndgetentropy.c:98:21: warning: implicit declaration of function 'getrandom'; did you mean 'srandom'? [-Wimplicit-function-declaration]
       98 |               ret = getrandom (buffer, nbytes, GRND_RANDOM);
          |                     ^~~~~~~~~
          |                     srandom
    /Users/ec2-user/gentoo/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/random/rndgetentropy.c:98:48: error: 'GRND_RANDOM' undeclared (first use in this function)
       98 |               ret = getrandom (buffer, nbytes, GRND_RANDOM);
          |
    ```
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Sam James <[e-mail]>

 dev-libs/libgcrypt/libgcrypt-1.10.1-r2.ebuild | 2 +-
 dev-libs/libgcrypt/libgcrypt-1.10.1-r3.ebuild | 2 +-
 dev-libs/libgcrypt/libgcrypt-1.10.2.ebuild    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

[Comment 28 Tom Li 2023-04-24 13:23:33 UTC]

I now confirm that, as of portage-20230423.tar.gz, prefix bootstrap is now functional on ARM64 macOS, finishing stage3.

However, two packages still need to be keyworded in order to start the prefix:

- app-portage/prefix-toolkit-9::gentoo_prefix (masked by: missing keyword)
- app-portage/prefix-toolkit-8::gentoo_prefix (masked by: missing keyword)

Without this package, startprefix script is unavailable. 

Also,

- app-shells/zsh-5.9-r4::gentoo_prefix (masked by: missing keyword)
- app-shells/zsh-5.9-r3::gentoo_prefix (masked by: missing keyword)

zsh is the default login shell on macOS, so startprefix wants to install it automatically. I tested it and it's functional.

[Comment 29 Tom Li 2023-04-24 14:59:30 UTC]

I just opened Pull Request https://github.com/gentoo/gentoo/pull/30730 to solve this problem.

[Comment 30 Larry the Git Cow 2023-04-24 20:13:58 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4002bff2a362bd96d18480740694b28cc82d681e

commit 4002bff2a362bd96d18480740694b28cc82d681e
Author:     Yifeng Li <[e-mail]>
AuthorDate: 2023-04-24 14:50:57 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-24 20:13:14 +0000

    app-shells/zsh: keyword ~arm64-macos.
    
    zsh is the default login shell on macOS. When the command startprefix
    is executed, by default, Gentoo prefix attempts to install the same
    shell within the prefix automatically. But it currently fails due to
    missing keywords. This commit adds the missing ~arm64-macos keyword
    to zsh. It's tested and shown to be functional.
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Yifeng Li <[e-mail]>
    Closes: https://github.com/gentoo/gentoo/pull/30730
    Signed-off-by: Sam James <[e-mail]>

 app-shells/zsh/zsh-5.9-r3.ebuild | 2 +-
 app-shells/zsh/zsh-5.9-r4.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce82e5c723cdb6474458f53d8ebbe99ff54ff204

commit ce82e5c723cdb6474458f53d8ebbe99ff54ff204
Author:     Yifeng Li <[e-mail]>
AuthorDate: 2023-04-24 14:46:14 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-04-24 20:13:14 +0000

    app-portage/prefix-toolkit: keyword ~arm64-macos.
    
    Currently, Gentoo Prefix cannot be started on macOS w/ Apple Silicon
    due to the missing ~arm64-macos in app-portage/prefix-toolkit, which
    contains the script "startprefix". Adding the keyword allows the
    prefix to start.
    
    Bug: https://bugs.gentoo.org/904474
    Signed-off-by: Yifeng Li <[e-mail]>
    Signed-off-by: Sam James <[e-mail]>

 app-portage/prefix-toolkit/prefix-toolkit-8.ebuild | 2 +-
 app-portage/prefix-toolkit/prefix-toolkit-9.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

[Comment 31 Tom Li 2023-04-24 20:32:49 UTC]

I believe all the keywords necessary for bootstrap have been added. This issue can be closed. Should more missing keywords appear in the future, the bug can be reopened or a new bug can be filled.