[gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Michael]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Dale]

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, 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. 

I hate when a drive goes bad.  :-( 

Dale

:-)  :-) 

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

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1072 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Michael]

[-- Attachment #1: Type: text/plain, Size: 7429 bytes --]

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?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13

[Dale]

[-- Attachment #1: Type: text/plain, Size: 8592 bytes --]

Michael wrote:
> 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?


Grasping at straws here.  Could it be that it was built against one
version of python but another is now installed and active, and not the
one it is built against? 

I looked at the USE flags on my system.  The only ones are for python
targets and test, which us lowly users don't use.  The only problem that
I can think of is a problem with python version. 

Another thought.  I have made the switch to python 3.13 but have other
versions installed for a few packages that need them.  This is what I
show for what python is selected. 



root@Gentoo-1 / # eselect python list
Available Python interpreters, in order of preference:
  [1]   python3.13
  [2]   python3.12 (fallback)
  [3]   python3.11 (fallback)
root@Gentoo-1 / #


If you still on 3.12, it may show it as selected, not fallback.  Anyway,
checking that and seeing what the system is working with might give a
clue.  Maybe.  It's another straw at least. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 11189 bytes --]