You are not logged in.
Pages: 1
[root@eurobuild6 /]# python3 /usr/lib/python3.7/site-packages/namcap.py
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/namcap.py", line 27, in <module>
import Namcap.depends
File "/usr/lib/python3.7/site-packages/Namcap/__init__.py", line 20, in <module>
from . import util, rules
File "/usr/lib/python3.7/site-packages/Namcap/rules/__init__.py", line 24, in <module>
from . import (
File "/usr/lib/python3.7/site-packages/Namcap/rules/kdeprograms.py", line 22, in <module>
import Namcap.depends
File "/usr/lib/python3.7/site-packages/Namcap/depends.py", line 27, in <module>
from Namcap import package
File "/usr/lib/python3.7/site-packages/Namcap/package.py", line 29, in <module>
import pyalpm
ImportError: libalpm.so.11: cannot open shared object file: No such file or directory
This might affect all slaves building pentium4 packages..
Offline
Diffing versions:
pentium4:
- namcap 3.2.8-3.0
- /usr/lib/libalpm.so.12 is owned by pacman 5.2.0-2.0
i686:
- namcap 3.2.8-3.0
- /usr/lib/libalpm.so.12 is owned by pacman 5.2.0-2.0
As the python library should link against libalpm.so.12 I'm quite puzzled seeing namcap
to be the same version on i686 and pentium4?
Offline
Is my slave broken again?
error: GPGME error: Invalid crypto engine
Offline
aha: pyalpm
pyalpm 0.9.0-1.0 is good, pyalpm 0.8.5-2.0 not.
I'll trigger a rebuild (though I'm wondering how I can trigger a pentium4 build using namcap
which is already broken, I might have to prepare a slave accordingly not to call namcap).
Offline
I spot another glibc/toolchain like set of packages here:
pacman -> pyalpm -> namcap
Offline
It only affects build slaves building new chroots, as long as they build normally, nothing bad happens. :-)
Offline
pyalpm had build issues lately (in check(): "no module named pyalpm") - are you sure, those resolved yet?
Also I doubt, that it only affects new build-chroots, because the packages in the buildroot get updated before building - no matter what.
Offline
Pages: 1