SliTaz Forum
You are not logged in.
For the time being, it seems that adding
[c]CONFIGURE_ARGS="CPPFLAGS=-I/sysroot/usr/include LDFLAGS=-I/sysroot/usr/include "[/c]
to /etc/slitaz/cook.conf
has been enough for the compiler and linker to find the files installed to sysroot when temporarily installing the dependencies...
... still a lot of things to do, though ...
Offline
So up to now, I reached the packages starting with "l" (so I already manually checked 1938 packages) and had to skip a good amount due to errors I will still have to resolve.
But I also managed to cook more than 500 packages already...
So when I am through with the first swipe, I will dig deeper into why other packages fail (most of them because installed libraries cannot be found. One example is pkg-config files that are to be found in subdirectories of /sysroot/usr/share/pkg-config but are ignored up to now...)
Another thing will be to ban gcc4.6 up to 8.3 and tune everything to use gcc 10.2 ...
Offline
Filou & shann,
Thanks for your effort on behalf of us Slitaz enthusiasts.
I'm not a coder, but if I could help with some testing, I'd be happy to lend a hand.
Will the new SliTaz be both 32 and 64 bit or 64 only?
Which init system will you use? Have you considered runit?
Offline
Okay,
I downloaded and explored Shann's slitaz_x64.tar.gz and slitaz-basevm.iso (frugal install) and Filou's 210209_LFS-wok.tar.xz and the chroot script.
I know how to setup the chroot, and think I can figure out how to build packages after reading the cookbook.
I have a few questions though:
1) Are you guys following the same rules/guidelines to build packages?
2) Which environment between slitaz_x64.tar.gz and 210209_LFS-wok.tar.xz should I use for development?
3) Where are the built packages uploaded/shared (the http://mirror.slitaz.org/packages/unstable/ link Shann indicated in a previous post does not seem to exist)?
4) How are you organizing the building of packages, what are the priorities?
5) Which kernel are you using (I couldn't find one in the LFS_wok or slitaz64)?
Offline
Hi sofia-m,
sorry for the late reaction, some "real-world challenges" to be addressed ...
I really appreciate your willingness to support!
So where are we up to now?
- We have a chroot environment built from LFS 10, that I "contaminated" with SliTaz scripts in order to produce a working x86_64 wok. Step by step, I am fiddling around with that environment (and the receipts) in order to gain more stability. At the moment, I am rushing through the packages to build a baseline of already (hopefully) working tazpkg's. Next goal is to reach a working minimum, bootable base image.
To answer your questions:
1) I guess so, yes. I do NOT intend to reinvent anything but to stick as close to what already exists. The LFS environment shall only be a bridge to cook the necessary x86_64 packages; after that I intend to start over with a "real" SliTaz image identical to the accustomed 32bit version, only containing of x86_64 packages. So no change to that.
2) I don't know if shann is still ongoing with his chroot. As far as I have seen, he managed to cook about 200 packages yet. During my alphabetical sweep through my LFS-wok, I reached around 600 packages up to now. I have to point out: I could not test yet, if these packages are fully functional or complete, because I don't have a running minimal x86_64 SliTaz running up to now. But if the cooking process doesn't throw out any errors, the files.list inside the package looks like the 32bit-version and the files are reported as being 64bit ELF packages, I believe I am on the right track.
So I'd suggest to proceed with the LFS wok, should shann not propose anything else.
3) Since I don't have any writing access to the repositories, I regularly add the packages to my webspace folder on web.de (as pointed out in a sooner post in this thread). I'd be happy to contribute to a common repository but up to now seemed quite lonely on this, so my webspace did not pose any problems. We should be able to find a solution for that one though.
4) To be honest, we (or I ...?!?) don't really have an organisation or clear priority list yet. On my journey of bit-by-bit improving the LFS wok, I now rush through everything alphabetically to have a base stock and then, as already mentioned, will concentrate on the packages that are contained in the rootfs4.gz - rootfs3.gz ... as an the cooking livecd.
Plan is, when a 64bit live-cd is running (X would be no must for a start), to build up a "pure" SliTaz wok to be sure that there will be no LFS- or 32bit-pollution in the system.
5) I use a 4.4.28 kernel, with aufs support but optimized for my ideapad i7 haswell. Since I did not build any modules other than those necessary for my hardware (graphics, sound, ...) I did not publish it with the LFS-wok. A 5.x kernel works on first glance but throws out memory allocation errors with my 32bit SliTaz rootfs, dunno why. I hope that 64bit will work fine with 5.x
Long story short: very happy if you'd like to help; there's little of "organisation" yet, just a dimly lit path I try to follow to realize the bridge to the 64bit world...
Offline
Hi Filou,
Thanks for your quick and articulate answers.
1) Clear!
2) Clear!
3) A) Did you have any contact with the developers in charge of Slitaz-next64 development? B) Are the packages in the http://mirror1.slitaz.org/packages/next64/ repo compatible with those you're building? C) Have you considered github as an alternative?
4) Makes sense to me. As I said, I can setup the LFS chroot on my laptop and try to build some packages. Also, I could install a development Slitaz 64 system (either traditional or frugal) on a spare partition for testing. I have read through the scratchbook and the cookbook, and it does not seem terribly complicated.
5) I have tried shann's slitaz-basevm.iso (which ships a 5.4.91 kernel) on a frugal install. It booted fine, but I didn't go much further than exploring the files. Is that the 5.x kernel you are referring to?
Getting a workable 64bit base system seems like a good plan.
Please let me know what I could do to help you.
My knowledge is limited (I have only made a Slitaz respin as a school project), but I'm willing to learn.
Offline
Hi sofia-m,
To answer of your questions,
I follow Slitaz guidelines, Filou also with LFS steps, and adapt them for Slitaz specs.
URL repo doesn't exist to ensure that tazpkg not try to fetch packages from cooking or another release present in mirror.
slitaz-basevm is very minimal stuff of packages to minimal usable x86_64 slitaz env.
slitaz_x64 tarball doesn't have kernel because goal to can be used as this on any distribution.
This tarball containt inside root home (aka root dir 
), "packages" directory that all packages i have build.
The main goal has to have base x86_64 system with dev tools, and also Xorg env.
With ~200 packages i have build, we have base x86_64 and toolchain with dev tools.
Packages inside next64 as begin by Aleksej, also work of Alaniyh, it's used 'old' toolchain GCC8, kernel 4.*.
My work has based on it, with updated toolchain.
Infact, it's more stuff, with good roadmap, guideline, organisation you can do it.
Thanks for your help, not necessary need to have developer, just report bugs, help to testing, help members of community 
.
Offline
Hi shann,
Tazpkg catch from cooking by default for deps, you can skip them by :
- use AUTO_INSTALL_DEPS="no" to /etc/slitaz/tazpkg.conf
or
- define notexist url in /var/lib/tazpkg/mirror (that my choice, point to http://mirror.slitaz.org/packages/unstable/)
URL repo doesn't exist to ensure that tazpkg not try to fetch packages from cooking or another release present in mirror.
Tazdev - SliTaz developers and build host tool.
http://hg.slitaz.org/slitaz-dev-tools/file/3a966a7b4ac9/tazdev/tazdev
# Tazdev - SliTaz developers and build host tool. System-wide config file
# is located at /etc/slitaz/tazdev.conf. Please, keep the code clear and
# well commented. Also keep in mind: configuration variables are $UPPERCASE
# and variables initialized by tazdev itself are $lowercase.
Offline
Architecture : i486
Kernel : 5.4.91-vm
Machine type : x86_64
slitaz-vm.iso
https://people.slitaz.org/%7Eshann/slitaz64-stuff/slitaz-basevm.iso
root@slitaz:~# uname -a
Linux slitaz 5.4.91-vm #1 SMP Thu Jan 21 14:46:42 UTC 2021 x86_64 GNU/Linux
root@slitaz:~# slitaz
SliTaz GNU/Linux
================================================================================
Release : cooking
Architecture : i486
Kernel : 5.4.91-vm
Machine type : x86_64
Home path : /home/slitaz
Configs : /etc/slitaz
Main config : /etc/slitaz/slitaz.conf
Log files : /var/log/slitaz
Packages DB : /var/lib/tazpkg
Installed : 22 packages
Mirror : http://mirror.slitaz.org/packages/unstable/
System date : Sat Feb 6 10:19:24 UTC 2021
--------------
Boot options : initrd=/boot/rootfs.gz rw root=/dev/null BOOT_IMAGE=/boot/bzImage
================================================================================
Offline
If slitaz-basevm.iso is the right environment to test the new packages, I'll install it on a spare partition.
Should I download the packages and install them locally or is there a way to configure tazpkg to perform get-install?
Offline
If slitaz-basevm.iso is the right environment to test the new packages, I'll install it on a spare partition.
Should I download the packages and install them locally or is there a way to configure tazpkg to perform get-install?
Offline
Hi alanyih and sofia-m
@alanyih
Infact, tazdev right way for create and use chroot env.
@sofia-m
Not really easy to identify right or wrong environement.
Infact, work i begin chroot, build packages and slitaz-basevm from stuff of Alanyih and Aleksej, in sense maybe right.
Filou try another way, build LFS to have base environment for build x86_64 packages.
@Filou,
For memory allocation errors, can you check with ulimit -a, "max memory size" value, you need to set them at unlimited and also data seg size (ulimit -m unlimited && ulimit -d unlimited)
tonight, i go to build tazpkg repository in my public folder "people.slitaz.org/~shann".
Offline
Hi,
I pushed all packages and configure repository for tazpkg.
http://people.slitaz.org/~shann/slitaz64-stuff/repo/packages/unstable
Unstable because always in progress .
I see fews missing deps, to example flex libtinfo for binutils need fix on receipt
Also need to use tazdev to have clean env for build.
Offline
@shann
Architecture : i486
slitaz-vm.iso
Please check /etc/slitaz/slitaz.conf
Offline
@shann
I installed slitaz-basevm.iso on a spare partition.
It boots boots fine, however, I can't chroot into it from the host system, get error:
# chroot /mnt/sda11 /bin/busybox ash
bash: chroot: command not found
Do I need to install some libraries or use another command?
Offline
Hi @sofia-m
Try...
get and install tazdev:
# tazpkg -gi tazdev
generate chroot environment:
# tazdev gen-chroot
enter the chroot environment:
# tazdev chroot
exit environment chroot:
# exit
Offline
Hi @rerivero,
I installed Slitaz-basevm in a spare partition, not a folder, which I'm trying to access from Devuan, to test packages while I do homework.
I might install some package providing the chroot binary on Slitaz-basevm, I suppose.
Offline
@shann
I tried both from Devuan and from a HD install of Slitaz 64 rolling.
The command I used are:
#mount -rw /dev/sda11 /mnt/sda11
# mount -t proc proc /mnt/sda11/proc
# mount -t sysfs sys /mnt/sda11/sys
# mount -o bind /dev /mnt/sda11/dev
# mount -t devpts pts /mnt/sda11/dev/pts
# cp -L /etc/resolv.conf /mnt/sda11/etc/
# chroot /mnt/sda11
chroot: can't execute '/bin/bash': No such file or directory
I had the same problem with Alpine Linux, which uses busybox chroot too. I could chroot into Alpine Linux partition only after installing the chroot package there. But maybe I'm doing something wrong.
Offline
@sofia-m:
Maybe you should try:
[c]chroot /mnt/sda11 /bin/sh --login[/c]
as SliTaz often does not have a bash installed by default but simply busybox' ash.
Invoking without parameters might look for the bash, although not installed ?!?
Offline
... slowly advancing on the trail...
In the last days, i took the original rootfs4.gz from a SliTaz 5.0 cooking LiveCD and replaced the installed packages by the x86_64 compiled packages (as published on my webspace:
https://c.web.de/@337942326598965997/QhaNFMiJQhuEqY3q66F8Xg ).
Since for some of the installed packages I did not yet achieve sane 64bit compilations (as for cdrkit for example) I just left them out for the first steps.
I achieved a bootable x86_64 Rootfs that I put on my webspace in the "Chroot-Systems" folder.
This is a packed cpio image as on the LiveCD.
You can extract them in order to chroot into them by typing (IMG being the name of the file) as root:
[c]( zcat "$IMG" 2>/dev/null || gunzip d "$IMG" -so 2>/dev/null || cat "$IMG" ) | cpio -id[/c]
I also managed to boot into the rootfs images using (any) kernel + module-overlay with the following grub4dos entries:
[c]title Slitaz from Scratch (SFS)
root (hd0,0)/SFS
kernel /bzImage
initrd /rootfs64.gz /ovl_modules.gz[/c]
For my frugal installations I always use a combination of the kernel and an overlay containing the kernel modules (which is simply the /lib/modules/[kernel] tree packed in a cpio as the other images).
You can produce such an overlay easily by building the tree and packing with:
'(find . -print | cpio -o -H newc ) | gzip -9 > /tmp/ovl_modules.gz`
The smaller 210227_rootfs.gz (7.3 MB) is my first try to take the step to the 64bit SliTaz image. The larger 210228_rootfs_wok.gz (62.2 MB) already contains most of the packages needed for a full wok.
While the first boots through mostly fine, the latter throws out a couple of errors. I guess, (e)udev doesn't start up at first, though after logging in as root and starting through again with
[c]/etc/init.d/rcS start[/c]
the image comes up in a sounder state.
Still a lot to do, but at least there's some x86_64 images running already and a steadily increasing pool of x86_64 packages that the LFS wok spits out.
I hope, these are usable for further steps ahead by you, too.
I am not sure, though, if they run fine under shann's chroot, since they are based on different glibs....
Will report further...
Offline
@Filou
chroot /mnt/sda11 /bin/sh --login did the trick, thanks a lot!
I have downloaded your rootfs64 and booted it with a 64 kernel in frugal mode.
Will try the overlay later.
Offline
@Filou
I have extracted the 210227_rootfs.gz and copied it to a spare partition. Then, I chrooted into it and installed the linux-4.17.7-x86_64 kernel from the Next64 repo.
Then I booted into it with a standard grub2 entry, and it booted just fine.
I copied shann packages to the /root/packages, just to have them handy.
Are there any packages you would like me to download from your website and test?
Offline
@sofia-m
I really appreciate your willingness to support, thank you!
At the moment I am struggling with extending the working but very bare Slitaz-x86_64 package to a full blown wok.
I managed to install many necessary packages, but still get some errors, which is why I do not dare to post it as a testing basis. At the same time, the bare package is just too ... bare ... to really test many things.
You could choose one of two possible tasks, if you like:
1.) you could download the latest LFS-wok.tar.xz (about 290 MB at the moment) from my webspace and try to cook further packages with it. As I was in the mid of the libraries, you could descend from the last packages in the wok down and meet me somewhere in the middle.
You will experience many packages failing the cooking process, but a good amount cooking well.
By that, we can a) extend the respository of available packages and b) identify which receipts need further work.
Just enter the LFS-wok with the enclosed chroot shellscript; you'll find the wok in /home/slitaz/wok and can cook the packages by simply typing [c]cook <pkg-name>[/c] . If it cooks well, you'll find the packages in /home/slitaz/packages...
or
2.) you could build up your installed bare image by installing the available packages and try to figure out, which packages break the installed system so we can search for errors in a more directed way.
Ba aware that the /var/lib/tazpkg/mirror file might point to a slitaz mirror and dependencies might be installed from a 32bit repository, breaking your system.
All installations will better be done with
[c]tazpkg -i <full-package-path/name> --nodeps[/c]
so that the dependencies are displayed but not collected from the repository.
A regular reboot should show, if anything has been broken.
Maybe this would be a step to take?!?
Thanks again!
Offline
@Filou,
I have already been toying with option 2) and was considering where to obtain a list of the packages that would constitute a minimal working distro.
For instance, this is the list of base-system packages from the rolling64 iso (without their eventual dependencies):
busybox 1.31.1 base-system
cookutils 887 base-system
dialog 1.3_20190211 base-system
e2fsprogs 1.45.5 base-system
gettext-base 0.19.8.1 base-system
glibc-base 2.14.1 base-system
kbd-base 2.2.0 base-system
libcomerr 1.45.5 base-system
linux 4.17.7 base-system
linux64 3.16.55 base-system
linux64-agp 3.16.55 base-system
linux64-crypto 3.16.55 base-system
linux64-drm 3.16.55 base-system
linux64-hfsplus 3.16.55 base-system
linux64-mmc 3.16.55 base-system
linux64-wireless 3.16.55 base-system
linux64-zram 3.16.55 base-system
lzlib 4.57 base-system
lzma 4.57 base-system
memtest 5.01 base-system
ncurses 6.2 base-system
ncurses-common 6.2 base-system
ncursesw 6.2 base-system
pcsc-lite 1.8.26 base-system
plop 5.0.15 base-system
slitaz-base-files 343 base-system
slitaz-boot-scripts 466 base-system
slitaz-configs 318 base-system
slitaz-configs-base 317 base-system
syslinux 4.06 base-system
tazinst 109 base-system
tazinst-gui 109 base-system
tazlito 529 base-system
tazpkg 944 base-system
tazusb 209 base-system
udev 182 base-system
util-linux-blkid 2.35.1 base-system
util-linux-eject 2.35.1 base-system
util-linux-getopt 2.35.1 base-system
util-linux-mount 2.35.1 base-system
util-linux-uuid 2.35.1 base-system
zlib 1.2.11 base-system
Some of them have a few dependencies which would, in turn have some more.
I don't know what you guys would consider an ideal base system.
I will play with the 5in1 images to see what packages each flavor ships with.
That might be a good starting point.
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]