This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------KGzaxVVZ3ny8avHztAePAggt
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/19/25 6:27 PM, Michael wrote:

No buildpkg on this system. :-(

Gentoo provides a large (45 gb) public buildpkg cache at https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart

I'm not sure how to
fix that. Basically, portage stores data on what is installed in /var
but the packages are in /, mostly /(s)bin and /usr. Basically, portage
thinks one thing but the truth is something else. I suspect emerge
isn't happy since it is so confused.

Emerge is not happy when it tries to use package versions which the filesystem
does not have installed yet. I'll try once more to tweak python targets in case I can get emerge to build a working toolchain. If that doesn't work I'll
fetch a stage 3, build what I need as binaries and then emerge them on the live system before I carry on.

With the public binhost you should be able to skip the stage3 and go
straight to emerging a binary toolchain. I'd suggest you should even use --getbinpkg --emptytree @world for consistency.



--
Eli Schwartz

--------------KGzaxVVZ3ny8avHztAePAggt--

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCaCu4EwUDAAAAAAAKCRCEp9ErcA0vV97d AQD7o+O3O5S6nnuLL0kcaEYUDUmrlvsLfdZ0PD/j8C8xNAD/XpCe/9mHu58ATUxBr6jC5GNLKVag Z+nvaDInUeuyzg4=
=7tTw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 19 May 2025 14:17:49 British Summer Time Dale wrote:

Michael wrote:

Just as I was celebrating the last python upgrade has been a breeze, a
disk
failed on one PC in the most inopportune moment. The / directory was on the SSD disk which failed. The /var/db, /var/cache and /var/log are on a different (spinning) disk.

I restored / from a backup which was 5 weeks old, excluding /var/db, /var/ cache and /var/log - I didn't have a backup of these. Consequently, there's an incongruity in what portage thinks is installed - a day old update status - and what is actually installed - 5 weeks old packages.

I tried to run an update @world, but it failed as some package versions were missing/incompatible. I tried to force python3_13 following the python upgrade guide, but may have ended up making things worse. What is the best way to bring this system up to date?

Do you have buildpkg set in make.conf? If you do, can you try a emerge
-ek world? That should reinstall to the version you have saved from all
the binaries you have. You may want to try -K as well. It tells it to
use binaries only. If you don't have buildpkg set,

No buildpkg on this system. :-(

I'm not sure how to
fix that. Basically, portage stores data on what is installed in /var
but the packages are in /, mostly /(s)bin and /usr. Basically, portage thinks one thing but the truth is something else. I suspect emerge
isn't happy since it is so confused.

Emerge is not happy when it tries to use package versions which the filesystem does not have installed yet. I'll try once more to tweak python targets in case I can get emerge to build a working toolchain. If that doesn't work I'll fetch a stage 3, build what I need as binaries and then emerge them on the
live system before I carry on.

I hate when a drive goes bad. :-(

Although I can't complain because this SSD lasted for more than 11 years, it was unfortunate it died just before I was about to take a fresh backup. A day later it wouldn't have mattered. Murphy's Law in action!

P. S. I hope you have a backup of /etc and your world file, just in
case you have to start over.

Yes, but I'm trying hard to avoid reinstalling.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmgrsEkACgkQseqq9sKV ZxllZA/8Dn1HZ2S5I/VZn+vb7qiFK6L9vxlKn5eVNBROdjfnvnHbvFNb7WDW1/59 KE2CV/hovRMnoRvSfKcYD2MHxa21bUym4rpZMDM746Rh1qk2HQayoGxM5bbgEDhZ m10uQPpmhBOkJj6rlvq9SfSOXUymPUuGwbh00In++GLtOdPOnQEh1xnSMrNYbS60 LprEdE9JLSI22Cl8/XMq4Ms1+kZ2Mdxkur7rVS0BmnhHGOSphB0vWcQRYwk8AY90 VJGc1l0aKJksth60jsm76U/1zJBcVkAh17/RMU1FfcrNPmbuWdhE2w0ns9GAlbh2 eUEyBqpZypLgGExyy2EyMm31sGSThAu6d0N4ZrTEW+WpKRY0hvhy1qICibbnF8uh 9P3iWbf09doqbDdmieQH0sM/s6K53ca/x4a6ozgN2Y0sNyvdFMzJLeonYFSycBe9 +iJvo+xiQ4wSPXL7igce4U5oEL5tCgOwKIFkaTRCnIbuvGiU4bKsyoO6QgU0weg8 dfLiw9/bF/aELKb1DNXNG/HAqYb9pJEyo2Ss1Pxw1jaXz6rl0x9UcXRJV8BAvcY+ q1Tdb4RShB5OrAnNvWr0wvLonljDcB405NZUbTE1rHtQtsAYpjv8Fc39jhkYjgxu sfpAUP5rasDaOCMImpG7E1tGt9c1OL/MV1jLzJHSf8Ip/yo92XA=
=yZEv
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 20 May 2025 00:00:35 British Summer Time Eli Schwartz wrote:

On 5/19/25 6:27 PM, Michael wrote:

No buildpkg on this system. :-(

Gentoo provides a large (45 gb) public buildpkg cache at https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart

I'm not sure how to
fix that. Basically, portage stores data on what is installed in /var
but the packages are in /, mostly /(s)bin and /usr. Basically, portage
thinks one thing but the truth is something else. I suspect emerge
isn't happy since it is so confused.

Emerge is not happy when it tries to use package versions which the filesystem does not have installed yet. I'll try once more to tweak
python targets in case I can get emerge to build a working toolchain. If that doesn't work I'll fetch a stage 3, build what I need as binaries and then emerge them on the live system before I carry on.

With the public binhost you should be able to skip the stage3 and go
straight to emerging a binary toolchain. I'd suggest you should even use --getbinpkg --emptytree @world for consistency.

Thank you Eli, I'll take a look at this approach as it will be a quicker option.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmgruOEACgkQseqq9sKV ZxldNBAA5UTNDWhJrSMG2n8Rqi2c7azWrdHMAeS45q2YE+s4vx6hxlYLs95lIipW HFkcGd8QagN5t+o4Cf/NcYJog6+HyqCTnFkUBsUSC/fU3LLBL6xSVIBvrIs06z1z AMmDKkRk7d4wmpV+nj5irelGXAHdpBJYqbLNqeV/TDQVXrPjucl/CTRjV0XGmHnF Q+DWN8/g8Dcw52cxjE/x23OAs2+YL1eAU4u6AtFCUrTB2Y48MRAtauErQjqTHXtN P2DG2DOq/netB7svyc2STQafl30D8rQAmAZ748o90efBzeawuCS8qCcuJbY4c5Ix Dkwt7L3mpUDitONXnLdE5baofO7U1HL+JH7+LxG0/gLxSuogwbtf4AjBEre+0vGx AI/ckYttUV1mpZZSW9yCUSlKCtPSsrhxNvqpsXH25koggBDojC9KeB8cAGd/1Ot9 GbZmRTRQoBgf6Jr7jfZw7f4/vBCIefGxHVa48wGAA1z0g+hS2kaf/K2Lx3lO90rj 2okXtdp3y+/XQu9+PQOrv+WtKBCrjAzAP/lL1T+9Qcpo1H4cKg+zLZkWTn/U3Zdn L4nlR+bCYOV6JAMEMGSdC9uKK2Fy22Qmm6HGuEMFlRUgVT4FodUrD6GeEnBkZk9r It6fEyJ5HdzfU738IZ3JRu99fStnVposeKbKgPh/ryx3YBDN9KA=
=GXKA
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 20 May 2025 00:04:01 British Summer Time Michael wrote:

On Tuesday, 20 May 2025 00:00:35 British Summer Time Eli Schwartz wrote:

On 5/19/25 6:27 PM, Michael wrote:

No buildpkg on this system. :-(

Gentoo provides a large (45 gb) public buildpkg cache at https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart

I'm not sure how to
fix that. Basically, portage stores data on what is installed in /var >> but the packages are in /, mostly /(s)bin and /usr. Basically, portage >> thinks one thing but the truth is something else. I suspect emerge
isn't happy since it is so confused.

Emerge is not happy when it tries to use package versions which the filesystem does not have installed yet. I'll try once more to tweak python targets in case I can get emerge to build a working toolchain.
If
that doesn't work I'll fetch a stage 3, build what I need as binaries
and
then emerge them on the live system before I carry on.

With the public binhost you should be able to skip the stage3 and go straight to emerging a binary toolchain. I'd suggest you should even use --getbinpkg --emptytree @world for consistency.

Thank you Eli, I'll take a look at this approach as it will be a quicker option.

I thought before I use binaries I better see how big the job ahead might be. I've set:

*/* PYTHON_TARGETS: -* python3_12 python3_13
*/* PYTHON_SINGLE_TARGET: -* python3_13

then tried to emerge python:

emerge -1aDv -e dev-lang/python

It wouldn't start because it complained packages (any/all) were masked by keyword. This is a stable OS, so I do not understand why it thinks stable versions are masked:

$ emerge --info | grep ACCEPT_KEYWORDS
ACCEPT_KEYWORDS="amd64"

Anyway, I tried it this way, which allowed all but 1 out 481 packages to
emerge successfully:

ACCEPT_KEYWORDS="amd64" emerge -1aDv -e dev-lang/python

Then this happens:

Source configured.
Compiling source in /var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/ qtwayland-everywhere-src-5.15.16 ...

* Running emake
make -j9 -l9.8
cd src/ && ( test -e Makefile || /usr/lib64/qt5/bin/qmake -o Makefile /var/ tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/qtwayland-everywhere-src-5.15.16/ src/src.pro CONFIG+=release CONFIG-=debug 'QMAKE_AR=x86_64-pc-linux-gnu-ar
cqs' QMAKE_CC=x86_64-pc-linux-gnu-gcc QMAKE_LINK_C=x86_64-pc-linux-gnu-gcc QMAKE_LINK_C_SHLIB=x86_64-pc-linux-gnu-gcc QMAKE_CXX=x86_64-pc-linux-gnu-g++ QMAKE_LINK=x86_64-pc-linux-gnu-g++ QMAKE_LINK_SHLIB=x86_64-pc-linux-gnu-g++ QMAKE_OBJCOPY=x86_64-pc-linux-gnu-objcopy QMAKE_RANLIB= QMAKE_STRIP=x86_64-pc- linux-gnu-strip 'QMAKE_CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CFLAGS_RELEASE= QMAKE_CFLAGS_DEBUG= 'QMAKE_CXXFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CXXFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 'QMAKE_LFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-- undefined-version' QMAKE_LFLAGS_RELEASE= QMAKE_LFLAGS_DEBUG= ) && make -f Makefile
make[1]: Entering directory '/var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/ work/qtwayland-everywhere-src-5.15.16_build/src'
cd qtwaylandscanner/ && ( test -e Makefile || /usr/lib64/qt5/bin/qmake -o Makefile /var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/qtwayland- everywhere-src-5.15.16/src/qtwaylandscanner/qtwaylandscanner.pro CONFIG+=release CONFIG-=debug 'QMAKE_AR=x86_64-pc-linux-gnu-ar cqs' QMAKE_CC=x86_64-pc-linux-gnu-gcc QMAKE_LINK_C=x86_64-pc-linux-gnu-gcc QMAKE_LINK_C_SHLIB=x86_64-pc-linux-gnu-gcc QMAKE_CXX=x86_64-pc-linux-gnu-g++ QMAKE_LINK=x86_64-pc-linux-gnu-g++ QMAKE_LINK_SHLIB=x86_64-pc-linux-gnu-g++ QMAKE_OBJCOPY=x86_64-pc-linux-gnu-objcopy QMAKE_RANLIB= QMAKE_STRIP=x86_64-pc- linux-gnu-strip 'QMAKE_CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CFLAGS_RELEASE= QMAKE_CFLAGS_DEBUG= 'QMAKE_CXXFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CXXFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 'QMAKE_LFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-- undefined-version' QMAKE_LFLAGS_RELEASE= QMAKE_LFLAGS_DEBUG= ) && make -f Makefile
make[2]: Entering directory '/var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/ work/qtwayland-everywhere-src-5.15.16_build/src/qtwaylandscanner' x86_64-pc-linux-gnu-g++ -c -march=native -O2 -pipe -fomit-frame-pointer -std=c++1z -fno-exceptions -Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -Wno-format-overflow -D_REENTRANT -fPIC -DQT_NO_LINKED_LIST -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_LINKED_LIST -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -I/var/tmp/portage/dev-qt/ qtwayland-5.15.16-r1/work/qtwayland-everywhere-src-5.15.16/src/ qtwaylandscanner -I. -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I.moc -I/ usr/lib64/qt5/mkspecs/linux-g++ -o .obj/qtwaylandscanner.o /var/tmp/portage/ dev-qt/qtwayland-5.15.16-r1/work/qtwayland-everywhere-src-5.15.16/src/ qtwaylandscanner/qtwaylandscanner.cpp
x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--undefined-version -Wl,--enable-new-dtags -o ../../bin/qtwaylandscanner .obj/qtwaylandscanner.o /usr/lib64/libQt5Core.so -pthread
make[2]: Leaving directory '/var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/ qtwayland-everywhere-src-5.15.16_build/src/qtwaylandscanner'
cd client/ && ( test -e Makefile || /usr/lib64/qt5/bin/qmake -o Makefile /var/ tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/qtwayland-everywhere-src-5.15.16/ src/client/client.pro CONFIG+=release CONFIG-=debug 'QMAKE_AR=x86_64-pc-linux- gnu-ar cqs' QMAKE_CC=x86_64-pc-linux-gnu-gcc QMAKE_LINK_C=x86_64-pc-linux-gnu- gcc QMAKE_LINK_C_SHLIB=x86_64-pc-linux-gnu-gcc QMAKE_CXX=x86_64-pc-linux-gnu- g++ QMAKE_LINK=x86_64-pc-linux-gnu-g++ QMAKE_LINK_SHLIB=x86_64-pc-linux-gnu-g+ + QMAKE_OBJCOPY=x86_64-pc-linux-gnu-objcopy QMAKE_RANLIB= QMAKE_STRIP=x86_64- pc-linux-gnu-strip 'QMAKE_CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CFLAGS_RELEASE= QMAKE_CFLAGS_DEBUG= 'QMAKE_CXXFLAGS=-march=native -O2 -pipe -fomit-frame-pointer' QMAKE_CXXFLAGS_RELEASE= QMAKE_CXXFLAGS_DEBUG= 'QMAKE_LFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-- undefined-version' QMAKE_LFLAGS_RELEASE= QMAKE_LFLAGS_DEBUG= ) && make -f Makefile
Project ERROR: Library 'atspi' is not defined.
make[1]: *** [Makefile:75: sub-client-make_first] Error 3
make[1]: Leaving directory '/var/tmp/portage/dev-qt/qtwayland-5.15.16-r1/work/ qtwayland-everywhere-src-5.15.16_build/src'
make: *** [Makefile:49: sub-src-make_first] Error 2
* ERROR: dev-qt/qtwayland-5.15.16-r1::gentoo failed (compile phase):
* emake failed

OK, I thought I better install what it seems to be complaining about, because it was not installed in this system:

ACCEPT_KEYWORDS="amd64" emerge -1av dev-python/pyatspi

However, it still complains:

# python -c 'import atspi'
Traceback (most recent call last):
File "<string>", line 1, in <module>
import atspi
ModuleNotFoundError: No module named 'atspi'

Apparently, it is a media-libs/assimp QT bug:

https://bugreports.qt.io/browse/QTBUG-84037

I've re-emerged media-libs/assimp, but the bug remains ... I wonder how it had been installed originally. Is there anything I can do about this?
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmgsxS4ACgkQseqq9sKV ZxlAfxAAnLjiYT25BCon4gKB7Cs9+X4leApqYrxX7a79N9XMN7k17Dbs/ATqmYd+ jyJq70Z6bh5hDXpHSmviDSDoWp06KZuoi8/WxFkpmF3biVhETxCFoqDZp05/+r9E wZhGMg3YXq4DPSvswWay3bb4psg2sF/C01Zu1zBdfh+1Zosarm49pZ3pn9RdKKsp JmkgrcvzjIpYV+LTVHW/tP1vbICxu1fn1hJd9VxzNwjVbu5wo7dtVK47ZurspioI ieiuDKxfDkAg6IBfcOz+Li33mztSEI1e4pkeCGSGYrxWRBXGUrgiJ9jYU4cIiqWy o2k1SVY47PcLKrv+unjtNkdA4gI+uH7SN7e4qkqB1eUol3CtqdV1GZwzmDiNEmvI /1A0vpBmweQF1OwFzadiG41bsEIdlu3nwLSudy3qyZQKfS4kY7fCK+8kgQkxtFUX aON3yAXFdK2JGAA+N2MmM/jGlKoDfJD7QOQdzUqWF1wPz2JrZPHBl21fuQ0aVnJo 5GxdCeCWZd6S5XP99mg8YEboWu7WtBh98XuAcWXTwId1J1lDS4osSNJlQZPPTb19 aOwWA7Ebf6zkFbzb1d+QwKc7unllujFGoW7H3N4k5tp33HNWrWwprZ7b5LOFucbq bqRUMmj0i8tXeNQIRSs6iNNCQXi7avCxaLypwxshjxCzg6QeVl0=
=cfRa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)