SliTaz Forum

Slitaz future?

(278 posts) (29 voices)

• Started 4 years ago by guest_account
• Latest reply from alanyih
• This topic is not resolved

Tags:

No tags yet.

1. 

   Filou
   

   offline

   Moderator

   I am just about to add my LFS version to the mentioned webspace ("210204_LFS.tar.xz") with a xz-compressed size of 216MB. (EDIT: done!)

   Since we use a different IP range, you'd have to copy your local /etc/resolv.conf to the LFS directory to be able to download additional stuff (like cloning your wok; since there is an SSL issue, you could enter export GIT_SSL_NO_VERIFY=true so that it will be accepted (I know about the security issues, but this is only a bridge to 64bit Slitaz in a chroot... ;-) ))

   So if you would like to fiddle around with it, feel free... ;-)

   Posted 3 years ago #
2. 

   shann
   

   offline

   Administrator

   Thanks :), upload new tarball in progress.

   For git you don't need use GIT_SSL_NO_VERIFY=true ;)
   Infact for git, it's doesn't use /etc/ssl/ca-bundle.crt, and just need to forced it to see inside.
   Create ~/.gitconfig or update it with :
   

   [http]
           sslCAInfo = /etc/ssl/ca-bundle.crt

   Also missing add readme for my chroot, you need add your /etc/resolv.conf inside :).

   Edit: Other tips for git command add in .gitconfig for command use less correcty without scroll
   

   [core]
           pager = less -F -X

   Posted 3 years ago #
3. 

   Filou
   

   offline

   Moderator

   ... just cooked tcl, tcl-dev and sqlite (will add them to webspace) and found that unzip was not available.

   When you play around with the chroot, remember that busybox is installed in /bin/busybox.

   Adding the symbolic link to /usr/bin/unzip was enough to go ahead... !

   Posted 3 years ago #
4. 

   shann
   

   offline

   Administrator

   I check-in after your message, /usr/bin/unzip exist and symlink in slitaz_x64 chroot.
   Maybe on your chroot, i don't check them in this time.

   EDIT: ok thanks for warning, i check in 210204_LFS.tar.xz, infact /usr/bin/unzip missing.

   Posted 3 years ago #
5. 

   Filou
   

   offline

   Moderator

   I am a fool....

   ... sometimes it's SOOOOO easy... >:-/

   libtool was unsuccessful because the linker was not available as foreseen. I didn't see that immediately, because the configure script only gave back, that ld would not be GNU....

   Creating a symbolic link from /usr/bin/ld to /usr/bin/x86_64-slitaz-linux-ld was enough!

   The latest cooks ran through fine...

   So let the cooking begin, I'll report as soon as I come to errors or will otherwise fill up my webspace with cooked x86_64 packages... !

   Posted 3 years ago #
6. 

   akm
   

   offline

   Member

   Sorry to ask: but why are you not using GNU ld? Why is it named x86_64-slitaz-linux-ld? I do not have any concerns, I'm just curious.

   Posted 3 years ago #
7. 

   mistfire
   

   offline

   Member

   Things need to be update for Slitaz.
   1. Xorg (with at least glamor support)
   2. Glibc
   3. icu
   4. libwebkit (to support newer CSS and html5)

   Posted 3 years ago #
8. 

   Filou
   

   offline

   Moderator

   @akm: in fact I AM using GNU ld, only the reported error message was about a non-GNU-ld, which pointed in the wrong direction.

   I guess that the symbolic link was necessary because the whole toolchain uses the prefix x86_64-slitaz-linux- (I took over the triplet that is used in x86 slitaz) and therefore libtool looked for the "included" ld...

   @mistfire:
   In order to be able to switch over to x86_64 ALL PACKAGES will have to be rebuilt.

   I hope that your short and snappy post was not meant as sort of "purchase order", 'cause if you read through this thread, it seems that shann and me are the only ones investing our time for this endeavour at the moment.

   So when you identified the need for new packages, I'd suggest that you download the latest LFS-wok I created and try to support us.

   It's still a long way to go, all we achieved up to now is a seemingly working x86_64 wok with almost the latest toolchain in a "Linux from Scratch" environment enriched with the wok scripts and from there, some 50 packages as a start.
   We WILL meet packages with errors we will have to resolve, so there's still lots of work to do.

   Your helping hand would be more than welcome, please don't just stand by, point to specific packages you would like to have first and wait for others to do the work...

   (sorry if I am writing too frankly... I don't mean to offend...)

   Posted 3 years ago #
9. 

   akm
   

   offline

   Member

   I really have neither much time nor skill, so I don't think I can be too much help, but I have a couple questions:
   1. Do I have to build Linux from Scratch (I'm not very good with Linux) and is it that
   hard for someone who knows the commands cd (change directory) ls (list contents) and
   basic vi (which isn't that hard :)) Will I come across things requiring deeper knowledge?
   Or will it just need a bootloader? Or chroot? (Still, would chroot or a bootloader be easy to handle?)
   2. I don't know how to test programs. Is that very time-consuming?
   3. Is gmake that hard? Is it the only requirement to help?
   4. What is a wok exactly? Is it a group of programs (their binaries or sources? or
   both?) in development? does the kernel count as part of the wok?
   5. You don't use make (a utility to build programs or applications I guess) to install
   your programs, but instead try authoring "control files" (I guess?) as well as
   preinstallation (before installation) and postinstallation (after installation) scripts,
   which help the package manager handle the installation, right?
   I might have used many words, but that's because I want to make it understandable for
   the dear reader;D

   Posted 3 years ago #
10. 

    Filou
    

    offline

    Moderator

    Don't mind for the questions (although some of them might be easily answered by some DuckDuckGo/Starpage/Google queries...)...

    1. The 210205_LFS-wok.tar.xz I pushed to my webspace (for the link look at one of the previous posts) is the RESULT of my compiling as LFS describes. So no, you don't HAVE to do it all yourself. But I recommend going through the procedure one time or another, because LFS describes quite clearly, how a linux system is set up and what the commands mean. Therefore, to gain a better understandig of what linux is about and how it is set up, LFS is a very good compilation.

    2. The testing is fast, but finding the errors and resolving them takes time. Sometimes LOTS of time...

    3. if by gmake you mean GNU make, it depends. Most programs are quite straightforward, as you just have to type ./configure && make && make install and the Makefile scans your system and makes all the necessary adjustments (as long as you have the necessary dependencies already installed). But the make system wouldn't really be the place to go for you. -> 4.

    4. The wok (or better the cookutils) is a system of scripts the genius founding fathers of Slitaz figured out to almost automatically produce ready-to-go packages (-> .tazpkg).
    As detailed in the "Cookbook" (to be found on the Slitaz Documentation page), for every package there is a "recipe" to be found that provides the details for the package: where the sources can be downloaded from, how it is compiled, which parts will have to be packed into which subpackage (for example readline and readline-dev or look at the util-linux subpackages...).
    So when your system is setup with a local wok (which is as easy as tazpkg -gi cookutils && cook setup-wok ) then you should be ready to cook packages with a simple cook <package> command.
    So far the theory; with the LFS-wok I have built, there should be an already working x86_64 wok.

    After unpacking (tar xz 210205_LFS-wok.tar.xz ) you can enter the environment with the provided "chroot" script (you are then enclosed in a chroot prison, that can't harm your host system, since the only way out is typing "exit". The chroot can't access your outer host file system.
    What you need are the recipes in the wok, shann has provided a link to his x86_64 wok somewhere in the other "Slitaz future" thread.

    With the recipes, you may start to cook packages by typing "cook <pkg>" and could support by testing, which packages build fine and where you encounter errors (and which ones). As soon as the wok proves to be stable and the recipes entail all the Slitaz-cooking packages, there will be a lot to do.

    5. should be answered by 4., since the task at hand is to build x86_64 packages to set up a 64bit-version of Slitaz...

    I hope I could be of any help and didn't puzzle you even more...

    Posted 3 years ago #
11. 

    akm
    

    offline

    Member

    Alright... should one use debian or SliTaz as the host system? Forgot to ask about that... And I'm also curious whether one needs a separate partition to work on it. It seems like it is worked on not in a separate partition, but a simple subdirectory (or a folder if you would rather call it that way).

    Posted 3 years ago #
12. 

    Filou
    

    offline

    Moderator

    The host system doesn't really matter, it's only important that your kernel supports aufs. (I hope that the aufs tools support any kernel, not just the 4.4.254 that I compiled)

    You don't need any extra partition, in fact I use Slitaz and unpack the folder into RAM (my Laptop has 16 GB RAM which makes a 64bit Kernel obligatory). If it fails unrecoverably, I just exit and delete it, otherwise I repack it and push the result back to my HD.

    Posted 3 years ago #
13. 

    Filou
    

    offline

    Moderator

    After the first packages went through quite well on the basis of shann's wok, I started over again using Christophe Lincoln's SliTaz Cooking wok available in the Slitaz Mercurial Repos (http://hg.slitaz.org/).

    Since LFS configures GCC to use /lib instead of /lib64 for x86_64 systems (see step 5.3, 6.18 and 8.26 on http://www.linuxfromscratch.org/lfs/view/stable/), many receipts from this wok compile fine as well after adding "x86_64" to the HOST_ARCH variable. A check, if newer versions of the package sources are available are helpful as well as the deletion of old patches.

    When the package fails, a closer look at LFS compilation configs might be of help.

    Happy cooking!

    Posted 3 years ago #
14. 

    akm
    

    offline

    Member

    Uhhhh... so you uploaded everything important to your webspace again? And you started from scratch, replacing Shann's receipts that make usable binaries out of the source code and the supplied makefiles and files named ./configure with the ones Christophe Lincoln (don't we call him Pankso?) made. Because Shann used experimental receipts made (or at least used) by Alanyih that makes things easier, right? Because Pankso's cooking wok is the more standard codebase for SliTaz, that I actually found to be maintained. Also, "cooking wok" has something to do with cookutils this time, but only in that it is a group of receipts for cooking all kinds of usable programs patched and maintained.

    Posted 3 years ago #
15. 

    Filou
    

    offline

    Moderator

    @akm:
    Well ... in general: yes.

    1.) shann's wok was a starting point for me in order to test my created wok. I was convinced that shann's receipts - already customized to x86_64 - were better than to use i486 scripts to start testing.

    2.) During the testing I found that the cooking sometimes failed for libraries that were searched in /lib64 - according to the receipts - but were not built there. It took some time for me te remember the information in LFS's steps as mentioned in my previous post. Therefore, the "original" receipts that are configured for the libraries to be in /lib instead of in /lib64 were even better suited due to the configuration that LFS introduced.

    3.) While experimenting with Pankso's wok, I found out that for many packages (I started alphabetically and went through to "D" now, with a good load of errors I'll explain in a minute) I just had to add "x86_64" to the HOST_ARCH variable and the cooking went through fine (as far as I can judge up to now. When extracting, it seems that the necessary files are contained and file gives back, that ELF64 packages have been built...). For a start, I added this quite bluntly by a simple
    find . -type f -name receipt -exec sed -i 's|HOST_ARCH=\"|HOST_ARCH=\"x86_64 |' {} \;
    (knowing that it might be doubled or create other problems later, but this is a START into a working x86_64 SliTaz, not the finetuning... !)

    4.) While shann seems to have invested a good amount of time, there are only 167 package receipts in his wok up to now. When looking at Pankso's wok, we speak about 5694 packages. So if we want to go to a running and complete SliTaz, I guess the path to follow should be quite clear.

    ---------------------------------------

    Up to now, my wok is able to create (what I would call "first level") packages, meaning all those that only show dependencies already available in the LFS environment.
    When needing more than that, many packages fail to find the respective include-libraries although the correct tazpkg-dev had been installed to the chroot. So I have to fiddle around some more to find out why either the packages are NOT installed though they are mentioned during the cooking process OR are installed but the library folder is not included in the library path. (or any other option I haven't figured out yet...)

    At this moment, I am uploading the 227 packages that have already been built according to Pankso's receipts and the latest version of my LFS wok for those who would like to contribute or play around by themselves.

    I'll continue to build the "first level packages" and to try to figure out what's wrong with the dependency-libs...

    Posted 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.