SliTaz Forum
You are not logged in.
That's probably not very helpful, but I looked at the hanging Python ([c]running build_py[/c]), googled it, landed at the "[c]setuptools[/c]" GitHub page, clicked on the "setuptools" folder and saw that compatibility with Python 2 was removed in some aspects (extension.py, monkey.py, namespaces.py,
unicode_utils.py, wheel.py ). I don't think the wok has Python 3. Then again, I didn't see a setuptools package in the wok either.
Offline
The package python3-setuptools should provide the setuptool files for python3.
It's correct that "python" still is linked to python2 (I found that some SliTaz packages still rely on Version 2, that's why it's still in...).
Python3 itself is provided by py3k and explicitely called with "python3", that's why some of the package receipts have been adapted accordingly...
If you cook meson for example, you'll see that all the site-packages are installed into python3.9 (and meson is running for many package cookings). Compilation of graphviz confirms that python as well as python3 are present (this is a dependency issue I will have to resolve, but the configure parameters only call for python3). So python3 is reported to be available...
I really appreciate your help though, could you be a little bit more specific about what you found out? e.g. what you have done exactly that brought you to your assumption? Thanx!
Offline
I literally just looked at the output of [c]cook protobuf-python[/c] and saw it hanging at [c]running build_py[/c]. I do not have any idea whether the error stems from the setuptools or a configuration mistake.
Offline
I googled build_py and saw a code file in github, so I looked several parent folders above that file (and landed in the folder [c]/setuptools/setuptools[/c]) and stumbled across "Python 2 compatibilty removed" as the last contribution to several folders. That's when I searched for[c]python3[/c] in the wok but I couldn't find a package named as such. When I searched for a package named [c]setuptools[/c] I must have stumbled across [c]python-setuptools[/c] and [c]python3-setuptools[/c] and dismissed them (that's a mistake on my side).
Offline
Thanx again! Finally, you pushed me on the right track...
The mistake was quite simple and the hint was at hand (stupid me): The README.md in the python folder of the protobuf sources state clearly: "make sure that [the protoc binary] is the same version as this package."
The protobuf binaries were of an older version (I only had updated the protobuf-python version number, but not the related protobuf, stemming from the fact that many python packages have a seemingly undependent versioning...).
So protobuf-python is online now, too and work can continue on this path as well...
Thanx again!
Offline
I used the [c]chroot.sh[/c] script, went to the [c]/home/slitaz/[/c] directory, executed [c]./get-wok[/c] and then [c]recharge tazpkg[/c] but when I tried to cook protobuf-python I got the following error message:
Extracting source archive "protobuf-3.17.3.tar.gz"
Executing: compile_rules
CFLAGS : -march=nocona -Os -pipe
Traceback (most recent call last):
File "/home/slitaz/wok/protobuf-python/source/protobuf-python-3.17.3/python/setup.py", line 17, in <module>
from setuptools import setup, Extension, find_packages
ImportError: cannot import name 'setup' from 'setuptools' (unknown location)
ERROR: cook failed
Offline
... strange, I just rechecked by unpacking my wok.tar.xz and performing exactly the same steps as you and protobuf-python was built successfully.
Maybe the database update in the repository was not finished yet? Could you please recheck?
If you still get the error, I just upload the most recent version of the wok, maybe this will help...
Offline
You see, after getting the error message I posted here, I actually messed around with the command [c]pip install -U setuptools[/c] and [c]python3 pip install -U setuptools[/c]. When it already ran, I got a warning that it ([c]pip[/c]) might break a lot of things when not run in a container seperate from the system and it probably did. (When I cooked [c]protobuf-python[/c] again, I got something about protoc not being installed, even when I reinstalled [c]python-setuptools[/c] and [c]python3-setuptools[/c]. I knew I wasn't on the right track.) So I just deleted everything, downloaded https://people.slitaz.org/~filou/rootfs/211229_rootfs64-wok.tar.xz that you just uploaded, and cooked again. It worked this time.
Offline
I just tried cooking [c]protobuf-python[/c] in another working directory, using the steps
1) run a linux (Filou's using SliTaz 5.0 with customized 64bit kernel) I'm using Debian 10
2) download https://people.slitaz.org/~filou/rootfs/210825_rootfs64_wok.tar.xz
3) cd to any working directory
4) tar xf [download_dir]/210825_rootfs64_wok.tar.xz (best as root)
5) chroot with ./chroot.sh
6) in the chrooted environment, cd to /home/slitaz/
7) get the wok with ./get-wok.sh
8) update repository with tazpkg recharge
9) compile things with [c]cook [package][/c]
for the second time today (first time was when I deleted everything) and it worked too. It may have been that I should have cleared the wok (which I don't know how to do) before using [c]./get-wok.sh[/c] again. Here's the output I got after using it a consecutive time today:
[c]mv: cannot move 'SliTaz64_wok' to 'wok/SliTaz64_wok': Directory not empty[/c]
But maybe has to do with time stamps.
Offline
No, you did everything absolutely right.
The error occurs, because git downloads the wok to the directory SliTaz64_wok, that is then renamed to wok.
Since this directory ("wok") already exists, you geht the error. Simply delete the wok (using rm -R wok) and pull it again, then you should be fine...
Beware that you delete any file that you already modified in the wok..., you could also just rename the "old wok"...
Offline
Just for everybody's information:
I built a script that tries to order all the packages depending on their dependencies.
On that basis, I started to recompile all the packages again, having a close look to use the latest package versions...
Meanwhile, updates from the repository might break any already installed SliTaz64 versions that use my repositiory...
I'll inform back as soon as I have finished...
Offline
One question: As far as I understand, [c]cook[/c] is a script that takes package receipts and uses them to make packages out of source code. If that is the case, what are the contents of receipts? They seem to use the [c]./configure[/c] scripts and the [c]make[/c] command, but wouldn't that make them scripts that don't need the [c]cook[/c] script? Or are they not written in bash? Are they only partially written in bash? Or does [c]cook[/c] take a bash script named [c]receipt[/c] and perform repetitive supplemental procedures? My bash skills are something I work on.
Offline
You are partially right.
The WOK is a set of scripts that automate the compilation of packages.
Since packages are quite different in compilation (some use configure/make/make install, some use autogen.sh in advance, some use cmake, some use meson/ninja ...), the wok is a tool to streamline this, so that the wok user just has to use one simple command: [c]cook {package}[/c]
The receipt contains the necessary information about the version number, the download path, the dependencies and the type of config/make process.
So yes,
- if you already have all dependencies and tools installed and
- if it's just a configure/make/make install type and
- if you just want to install the program
you don't need the wok and don't need any recipes.
But if you want to have rather simple system (where the necessary know-how is contained in the recipes, just like in the kitchen) and want to create a distributable PACKAGE, then you need - in addition to just installing the files - a tool that packs all the related files (and only them, or to be more precise, just the necessary files, that's why SliTaz is so small) into a package, that can be controlled concerning installation/uninstallation by a package manager (which is tazpkg for SliTaz or apt for Debian-based distributions).
Long story short: the wok:
- streamlines the building
- eases life as soon, as all information is in the receipts
- and creates packages, that every user can download from the repsitory
- and provide a means to keep your system clean if you uninstall a package...
You will find detailed information in the SliTaz Cookbook:
https://doc.slitaz.org/en:cookbook:start
Offline
So for information (whoever is interested):
I rebuilt the whole wok, stripped it down to the absolute necessary packages and updated these to the latest versions (apart from gcc and glibc, which would mean a restart from absolute scratch...).
Why? Because I realized that if not carefully monitored, cooked packages might find their dependencies in the wok and not from the repository, "polluting" them. This might lead to the fact, that installed packages search for the wrong version of a dynamically linked library.
I uploaded the new wok version to https://people.slitaz.org/~filou/rootfs/ as always. Feel free to play around with it.
Beware: I didn't put bash into the wok, so some packages might not build if the build scripts depend on bash and bash ist not mentioned in the BUILD_DEPENDS variable...
At the moment, I mass-recompile packages (having build the first ~500 packages this morning) and hope to be highly up-to-date soon... ;-)
Offline
Sorry, but one question: did you rebuild the whole wok after stripping it down to the absolute necessary packages or before that?
Offline
The starting reason for the rebuilding was that I experienced (in py3k in this case), that libffi.so.7 was requested by a package but libffi.so.8 was installed.
I then built a script that successively sorts the packages by dependencies, so that the dependencies should all be built before they are needed (which fails in the long run due to some circle dependencies, but will work for the first couple of thousand packages).
When I realized, that the problem might also arise from packages that are already contained in the wok, I decided to strip the Wok down and rebuild it.
Therefore, I
- stripped down the rootfs to a bare minimum of packages to still function as a rootfs
- identified the necessary packages by re-installing the toolchain into a test-rootfs
- sorted the necessary packages by inter-dependencies
- recompiled the most recent versions of the packages
- set up the new Wok with the recompiled packages.
If I did everything right (and my script works - I will publish that soon), then successively cooking all the packages should lead to a coherent system.
Offline
Hi Filou,
Happy new year 
.
At begin, congrat for your stuff.
You are right to rebuild wok in this steps.
It's important infact to build package in sanity env to avoid wrong linking library.
That's why cook use aufs and chroot method (install basic rootfs + dev tools), and use aufs to build packages (install depends up on rootfs with overlay and clean after build).
I need take the time to try your rootfs and toolchain, also cookutils to have cooker env (similar to https://cook.slitaz.org/next64/).
Offline
Hi shann,
thank you, happy new year to you, too! :-)
The cooker env for next64 is impressive and would indeed be a huge step forward again.
I'd be very happy if I could contribute with a working cli version behind it.
Just be aware, that I had to make slight adjustments in the cooker scripts that should be easy to highlight. I could do that during the weekend by providing the diffs, if that helps.
In addition, tazpkg downloads and installs packages just fine, but fails for [c]tazpkg up[/c] because it still makes a comparison between [package]-[Version].tazpkg and [package]-x86_64-[Version].tazpkg, which will still have to be resolved...
Looking forward to our cooperation!
Offline
I just uploaded my "Receipt-sorting-script" to
https://gist.github.com/F1lou/af763c03f2640bc8f75353948a14ba9f
Offline
Can you execute the script in the chroot environment itself? Or does that damage anything?
Offline
The script can be executed inside the chroot.
It just produces a .txt file in /tmp containing the sorted list...
Offline
Happy New Year to everyone.
Hello Filou.
Is it time I can help test SliTaz's 64bit ISO?
Grateful.
- - - - -
Feliz ano novo para todos.
Olá Filou.
Por acaso já é o momento que eu posso ajudar a testar a ISO de 64bits do SliTaz?
Grato.
Offline
Hi marcelocripe,
I have a quite busy time at the job at the moment, so it will take me a little to produce a (new) ISO... but will do so soon, please stand by...!
Offline
What happened?
Offline
Hi everyone.
Really sorry, I had some health issues to deal with, a lot of work at the office and my family wanted some more attention especially during the summer months.
I will take up business again soon, refocusing on the SliTaz 4.0 Scripts since 5.0 has become quite crypted...
Please have some patience with me....
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.59 MiB (Peak: 1.77 MiB) ]