not a support questionHi Gibor,
Thanks for you time to help and test.
for libpthread.so, infact because i set justx image i don't install devs env inside.
(libpthread.so provided by glibc-dev)
Nice to see that you have successfull build.
I go to create a new vm and use my rootfs justx to ensure no corrupted or wrong fs.
Hi gibor,
I test with iso https://people.slitaz.org/~shann/slitaz-4.0-stuff/slitaz-4.1-basedev-20220519.iso and wok https://people.slitaz.org/~shann/slitaz-4.0-stuff/stuff_justx_wip/wok/.
For slim same issue need use cmake twice for configure.
-- Checking for one of the modules 'fontconfig'
CMake Error at /usr/share/cmake-3.19/Modules/FindPkgConfig.cmake:805 (message):
None of the required 'fontconfig' found
Call Stack (most recent call first):
cmake/modules/FONTCONFIGConfig.cmake:18 (pkg_search_module)
CMakeLists.txt:108 (find_package)FontConfig Found
PAM disabled
ConsoleKit disabled
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring incomplete, errors occurred!
See also "/root/slim/source/slim-1.3.6/build/CMakeFiles/CMakeOutput.log".
See also "/root/slim/source/slim-1.3.6/build/CMakeFiles/CMakeError.log".
root@slitaz:~/slim/source/slim-1.3.6/build# vi /root/slim/source/slim-1.3.6/build/CMakeFiles/CMakeError.log
root@slitaz:~/slim/source/slim-1.3.6/build# cmake -Wno-dev -DCMAKE_BUILD_TYPE=Release -DCMAKE_SKIP_RPATH=ON -DCMAKE_INSTALL_PREFIX=/usr -DX11_Xmu_LIB=/usr/lib/libXmu.so -DX11_Xft_INCLUDE_PATH=/usr/includ
e -DX11_Xmu_INCLUDE_PATH=/usr/include -DUSE_CONSOLEKIT=no -DUSE_PAM=no ..
-- Enable shared library building
FontConfig Found
PAM disabled
ConsoleKit disabled
-- Configuring done
-- Generating done
-- Build files have been written to: /root/slim/source/slim-1.3.6/build
root@slitaz:~/slim/source/slim-1.3.6/build#
You have sucess build slim / pango with chroot justx ?
I'm afraid if i have packages broken.
@shann
PACKAGE="mesa"
VERSION="20.3.4"
....
# libGLU && libGLw removed from Mesa 20.3.4# libOSMesa is included in the package libos-mesa
rm -r -f $fs/usr/lib/libOS*
please check 'package libos-mesa'
Hi alanyih,
Thanks, i see that i have not build libos-mesa (not found in packages, forget) :/.
It's done and i update http://people.slitaz.org/~shann/slitaz-4.0-stuff/stuff_justx_wip/repo-packages/
Hi Shann,
it is not easy to communicate when I only know my native language well....
With chroot, tazpkg doesn't work well for me (it doesn't uninstall, and cook needs it).
In real disk installation, which I ran all the tests with, graphics doesn't work (xorg can't find the screen) eudev problems or xorg... I don't know ;-) as an inveterate nerd I have only ever worked in text mode.
I'll share with you your slitaz-4.1-basedev-20220519.iso repackaged after I used it on my hard disk. It contains everything you need to compile slim.
Double check the receipts which are different from yours. I do not run patches outside of
+#install(TARGETS slimlock RUNTIME DESTINATION bin)
I rebuild the fontconfig package and install it. Then I cook libjpeg-turbo and install it. Finally I cook slim and everything runs without errors.
For pango is a separate topic, but it becomes too long to address here.
N.b:
Your sources not being accessible to me by tazpkg, I cloned them into /var/cache/tazpkg/shann/packages then instructed the tazpkg setup-mirror accordingly.
In the repackaged root for space reasons they were removed. If you want to reuse it you have to put them back, or redirect the packages manager to your repositories.
I hope with this I explained myself well :-)
The file rootfs (~197Mb)
https://disk.yandex.com/d/L2NBJOEO9sDSrQ
Ciao Shann,
non è semplice comunicare quando conosco bene solo la mia lingua madre...
Con il chroot non mi funziona bene il tazpkg (non disinstalla, e cook ne ha bisogno).
In installazione reale su disco, cosa con cui ho eseguito tutte le prove, la grafica non funziona (xorg non trova lo schermo) problemi di eudev o di xorg... non lo so ;-) da incallito nerd ho lavorato sempre e solo in text mode.
Ti metto in condivisione la tua slitaz-4.1-basedev-20220519.iso reimpacchettata dopo che l'ho usata sul mio hard disk. Contiene tutto il necessario per compilare slim.
Controlla bene i receipt che sono differenti dal tuo. Non eseguo patch al di fuori di
+#install(TARGETS slimlock RUNTIME DESTINATION bin)
ricostruisco il pacchetto fontconfig e lo installo. Poi cucino libjpeg-turbo e lo installo. Infine cucino slim e tutto scorre senza errori.
Per pango è discorso a parte, ma qui diventa troppo lungo affrontarlo.
N.b:
I tuoi sorgenti non essendo a me accessibili dal tazpkg, li ho clonati in /var/cache/tazpkg/shann/packages poi istruito il tazpkg setup-mirror di conseguenza.
Nella root reimpacchettata per motivi di spazio sono stati rimossi. Se vuoi riutilizzarla devi rimetterli, o reindirizzare il packages manager ai tuoi repository.
Spero con questo di essermi spiegato bene :-)
Il file rootfs (circa 197Mb già compresso in lzma)
https://disk.yandex.com/d/L2NBJOEO9sDSrQ
@gibor
Thankx.
Summary for: slim 1.3.6 =========================================================================== Source dir : 6.2M Src file : slim-1.3.6.tar.gz Src size : 228.0K Produced : 2.7M Packed : 268.0K Compressed : 77.6K Files : 10 Cook time : 12s Cook date : 2022-06-22 16:21 Host arch : i486 ===========================================================================
----
+#install(TARGETS slimlock RUNTIME DESTINATION bin)
Executing: compile_rules
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- CMakeLists.txt 2022-06-18 19:10:05.000000000 +0200
|+++ CMakeLists.txt 2022-06-18 19:10:18.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
----
compile_rules()
{
patch -p1 < $stuff/$PACKAGE-$VERSION.patch || return 1
mkdir build; cd build
Hi Alanyih, the patch is in:
/home/slitaz/wok/slim/stuff/slim-1.3.6.patch
and the compilation runs correct
Cook: slim 1.3.6
================================================================================
QA: checking package receipt...
QA: Unable to reach: http://slim.berlios.de/
sh: bad number
Checking build dependencies...
Extracting: slim-1.3.6.tar.gz
Executing: compile_rules
patching file CMakeLists.txt
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0.
-- Detecting C compiler ABI info......
.
.
================================================================================
Package: slim-1.3.6.tazpkgSummary for: slim 1.3.6
================================================================================
Produced : 2.8M
Packed : 320.0K
Compressed : 84.0K
Files : 10
Cook time : 16s
Cook date : 2022-06-22 13:23
================================================================================
There is still an error... but it's my fault :-/ I removed before the recompression of the root, the folder /home/slitaz/xml
just recreate it that the error disappears
mkdir /home/slitaz/xml
Just to clarify I had been testing with pango, which was prompting me for various packages, including gtk-doc and down the various libxml. Hence when I thought about leaving out pango, I removed too many folders....
@gibor
|--- CMakeLists.txt 2022-06-18 19:10:05.000000000 +0200
|+++ CMakeLists.txt 2022-06-18 19:10:18.000000000 +0200patch -p1 < $stuff/$PACKAGE-$VERSION.patch || return 1
patching file CMakeLists.txt
Hunk #1 succeeded at 221 (offset -3 lines).
I use your patch
patch -p1 should be patch -p0
Hi Gibor,
Thanks, with your rootfs and packages send yesterday i think maybe found root cause.
fontconfig, pango not same version as me.
Fontconfig 2.10.91 vs 2.13.1
pango 1.29.4 vs 1.48.11
With fontconfig 2.10.91, i build successful slim 1.3.6 without issue with cmake (also with all patchs).
remain issue with pango and also about tazpkg inside chroot (maybe missing requirement).
I continue investigate in this.
I don't put much stock in versions, however I tried again compiling fontconfig and fontconfig-dev version 2.13.1. on my shared root, and I had to build the gperf-3.1 package again and install it, then again compiled fontconfig and slim and it all went well... (with my receipts).
Now I leave the ball to the experts, I have already written that I am a novice with cook. ;-)
Hi,
I found and fix issue about pango, seem deps and cairo version.
cairo 1.16.0 > need to be 1.17.2 for pango 1.48.2
for slim, at time not found why need cmake twice for sucessfull configure.
freetype 2.10.4 ok
fontconfig 2.13.1 ok
cairo 1.17.2 ok
pango 1.48.2 ok
slim 1.3.6 ok (with twice cmake)
openbox 3.4.11 ok
For tazpkg can't uninstall, it's because /dev/shm /dev/pts not mounted inside chroot.
I reproduce problem just with chroot rootfs_justx, with bind /dev/pts /dev/shm, /proc, /sys work as well.
i begin recreate justx with follow flavor (minus hal/udev stuff replace by eudev ^^) to go my test on laptop
Hi everyone,
sorry for having been so silent for such a long time. But I'm still here and still devoted to SliTaz!
I might be wrong but I have the feeling, that the main topic of this thread has somehow gone lost, hasn't it? Shann started a strategic discussion about how to proceed with SliTaz, about 4.0 and cooking, about 32 and 64 bits. I now have the feeling, that you slipped into technical details...?!
I somehow got stuck with my first one and a half rounds of compiling many packages with SliTaz receipts in 64 bits. From the first successes (which I published at that time) I don't agree, that 64 bits mean losing the "Tinyness" idea of SliTaz.
I am typing this using my 64bit startup, using a 4.2.8 Kernel and recent versions of openbox/lxpanel/pcmanfm including even Abiword and Gnumeric, Asunder, MtPaint, Geany and Sylpheed. All this sums up to about 65MB, which means without those extras we are not really far from the 50MB before.
I am using Firefox 100.x as well as Palemoon 31.x and SeaMonkey 2.53.x from temporarily mounted Squashfiles as well as FreeOffice 2021, so even the latest Desktop work is possible on my Intel Core 2 Duo from Anno 18xx...
I am about to restart from scratch during the rainy and darker months of the year, building another environment from Linux from scratch and using the scripts from SliTaz 4.0 this time (I agree, that 5.0 has become that minimalistic that the code is nearly unreadable for any non-full-professional).
So what do I want to say?
Strategically, I guess staying with 32bits would be a very niche existence. If SliTaz shall be widely usable, we will have to go for 64 bits. The more the core Desktop tools only go for 64, the more we will have to follow...
That doesn't mean, that I propose to drop the 32bit business, since many will stay with SliTaz mainly for that. I just mean we will probably have to change the focus.
I will happily try to support the 64bit side of the way...
So let's keep on going, folks !!!
Cheers! :-)
Hi Filou, akm
Infact, maybe dispatch with most technical details due of upgrade stack.
For sum up, i agree with you, we need support two arch, 32 bits and 64 bits.
I continue stuff, i hope to have usuable version end of year :)
Regards
You guys are doing such a great job! Love you <3
Shann, I hg pushed some stuff to the website repo but the site did not update automaticaly as before.. and can't login via ssh! Do you have an idea why :-)
You must log in to post.
