From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13
Date: Tue, 20 May 2025 13:42:59 -0500 [thread overview]
Message-ID: <a9e62875-b963-2a5a-07b9-6a4ca61f8590@gmail.com> (raw)
In-Reply-To: <116523174.nniJfEyVGO@rogueboard>
[-- 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 --]
prev parent reply other threads:[~2025-05-20 18:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 9:30 [gentoo-user] Filesystem with python3_12, but /var/db,cache with python3_13 Michael
2025-05-19 13:17 ` Dale
2025-05-19 22:27 ` Michael
2025-05-19 23:00 ` Eli Schwartz
2025-05-19 23:04 ` Michael
2025-05-20 18:08 ` Michael
2025-05-20 18:42 ` Dale [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9e62875-b963-2a5a-07b9-6a4ca61f8590@gmail.com \
--to=rdalek1967@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox