I’m trying to run a slightly old yocto build project on Manjaro that previously was only tested on WSL Ubuntu. I’m getting this error:
Traceback (most recent call last):
File "/home/slawo/Work/project/poky/bitbake/bin/bitbake", line 24, in <module>
from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
File "/home/slawo/Work/project/poky/bitbake/lib/bb/main.py", line 24, in <module>
from bb import cooker
File "/home/slawo/Work/project/poky/bitbake/lib/bb/cooker.py", line 25, in <module>
import pyinotify
File "/home/slawo/Work/project/poky/bitbake/lib/pyinotify.py", line 55, in <module>
import asyncore
ModuleNotFoundError: No module named 'asyncore'
With some googling I came to the conclusion that I need the python-pyasyncore package from AUR, I’m not very familiar with python or yay.
yay -S python-pyasyncore
...
==> Making package: python-pyasyncore 1.0.4-1 (Thu 09 May 2024 10:51:26 CEST)
==> Retrieving sources...
-> Cloning pyasyncore git repo...
Cloning into bare repository '/home/slawo/.cache/yay/python-pyasyncore/pyasyncore'...
remote: Enumerating objects: 38, done.
remote: Counting objects: 100% (38/38), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 38 (delta 12), reused 30 (delta 5), pack-reused 0
Receiving objects: 100% (38/38), 23.14 KiB | 1.22 MiB/s, done.
Resolving deltas: 100% (12/12), done.
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
pyasyncore ... Passed
:: (1/1) Parsing SRCINFO: python-pyasyncore
==> Making package: python-pyasyncore 1.0.4-1 (Thu 09 May 2024 10:51:27 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating pyasyncore git repo...
==> Validating source files with sha256sums...
pyasyncore ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of pyasyncore git repo...
Cloning into 'pyasyncore'...
done.
Switched to a new branch 'makepkg'
==> Sources are ready.
==> Making package: python-pyasyncore 1.0.4-1 (Thu 09 May 2024 10:51:28 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting build()...
/usr/bin/python: No module named build
==> ERROR: A failure occurred in build().
Aborting...
-> error making: python-pyasyncore-exit status 4
-> Failed to install the following packages. Manual intervention is required:
python-pyasyncore - exit status 4
How can I get more info on this build error or what manual intervention it needs?
I see the yay build project in $HOME/.cache/yay/python-pyasyncore/pyasyncore/ but there are no logs.
The first general AUR thing is that base-devel is required.
sudo pacman -Syu base-devel
Because this is a python error … I might ask have you installed python things from outside the package manager? And/or possibly committed something like sudo pip ?
yes, I have base-devel installed, I got this “install toolchain dependency” script with the project that had the ubuntu dependencies, so I converted it for manjaro based on previous errors and google
I tried to run pip once and it gave me a message how it is an externally managed environment so I canceled and googled into the topic and didn’t run it.
Also python-build is installed, checked just in case
$ sudo pacman -S python-build
warning: python-build-1.1.1-1 is up to date -- reinstalling
One last thing that comes to mind is that I had to make valgrind work last week, so I switched to unstable and then back to stable branch, so many packages are ahead of the stable branch on my system. Maybe that causes a problem?
Also in a quick manual setup it seams to work:
$ type python
python is hashed (/usr/bin/python)
$ ls /usr/bin/python
lrwxrwxrwx 1 root root 7 Apr 23 11:16 /usr/bin/python -> python3
$ python
Python 3.12.3 (main, Apr 23 2024, 09:16:07) [GCC 13.2.1 20240417] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import build
>>>
>>> import buildF
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'buildF'
>>>
>>>
>>> import build
>>>
As far as I can tell I’m not mixing. Or is installing from AUR count as mixing?
Regarding the ln I know its dirty, but I ran into this problem and until stable catches up to last weeks unstable that’s the only thing I can do because I can’t downgrade back to stable:
While its good not to do it, sometimes it’s the best that is available.
Package managers really should gain some sane way to manage hacks like this.
How easy would it be to tell pacman that libalpm14 provides libalpm13 and have a centralized place to manage it instead of just links you hopefully remember.
The real issue here is the attempt to use AUR while using Manjaro stable branch.
Issues like this on Manjaro stable branch is exactly why custom AUR scripts should not be available for stable branch.
There is a reason when a shared object changes primary version - usually it means breaking changes - so when symlinking an older library to a newer or the other way around - you are actually introducing unknown variables into your system.
And when you try to find those - it is like looking for a needle in a haystack - and when you don’t find it you open an issue with upstream ArchLinux pacman developers which then reject your issue and you blame them for a superior attitude.
you can try and explain it away in this case, but it was not my argument. My argument was that sometimes it’s the only option. And for that case, sane support should be provided instead of leaving everyone to improvise in any which way.
“Do not put diesel into an unleaded engine.”
“OK, but sometimes I only have diesel, so instead of telling me not to do it, the engine should provide some way of processing diesel.”
(also: “Whats wrong with my car?”)
can you comprehend there existing a situation where the needed library simply is not available? Your solution is to not use the software? My solution is to use it in “compatibility mode” where you know it might work fully or barely, but at least it works somehow instead of not at all.
How you could oppose this kind of idea is baffling.
edit: i did not name call, i called out your analogy. Please don’t try to instill undue hostility on me.
If you mean by your example that an otherwise clean and well managed system, during some course of use like … development or forensics … for some reason needs to create a false placeholder for a now defunct library, but that its not a system critical component, blah blah … well then sure, that user is competent enough to know what they are doing and I dont really know why they need some package management component to handle this for them when it should be strictly outside of system package management.
If on the other hand you are talking about some form of misuse where you are trying to establish and patch over a partial-upgrade state then everything about it is the wrong approach.
Back to the original analogy … maybe I should have flipped it.
Because a diesel engine can accept small amounts of unleaded from time to time. In fact under certain conditions, like low fuel and lower temperatures, a small addition of unleaded may even be helpful. But still one should not attempt to run their diesel vehicle using unleaded gasoline in general.
In these ways I actually find the analogy apt.
(To say nothing of the extra intentions like humor)
