SliTaz Forum

SliTaz Development strategy direction

(140 posts) (12 voices)

• Started 2 years ago by shann
• Latest reply from shann
• This topic is not a support question

Tags:

No tags yet.

1. 

   shann
   

   offline

   Administrator

   Hi,

   i synchronize locally 4.0 repo,put my updated packages, remove old to avoid mismatch.
   After cook pkgdb and switch to local repo, install slitaz-configs, xorg stack, openbox, midori to have "justx" flavors.

   My previous message about test not to afraid, normally new base backward compat with 4.0 ;).
   But can be break, example with libffi / ncurses lib requirement (workaround in place and fix it).

   

   Attachments

   1. slitaz_4.0_justx_newbase.png (276.9 KB, 381 downloads) 2 years old

   Posted 2 years ago #
2. 

   gibor
   

   offline

   Moderator

   Hi, doing graphics testing I think is premature. I think it's better to finish updating gcc and glibc.
   In this regard I would like to say a few words about the method to update the old 4.0: once you have done the first jump of gcc, you have to go to the final version you think to use (in my tests I stopped at 10.2.0). Then you can recompile all the others, taking care not to fall into the trap of some sources that completely change dependencies, generating a snowball effect on the entire distribution (e.g. pcmanfm lxpanel and various gnome packages).
   For those, working a bit on them with patches, you can keep them unchanged, while working with recent libraries. I've spent a lot of time on those patches and if needed (and you agree) I can also try to provide them directly.
   At least this has been my method to get a 64bit (real) LFS 10 version of slitaz. Otherwise, due to dependency bindings, following the needs of the sources generates more or less similar operating systems as it happens in many other distributions.

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

   Ciao, fare testing sulla grafica credo sia prematuro. Credo sia meglio terminare l'aggiornamento di gcc e glibc.
   Al proposito vorrei dire due parole sul metodo per aggiornare la vecchia 4.0: una volta fatto il primo salto di gcc, occorre portarsi alla versione finale che si ritiene utilizzare (nelle mie prove mi sono fermato alla 10.2.0). Poi da li si ricompila tutti gli altri avendo cura di non cadere nel tranello di alcuni sorgenti che virano completamente le dipendenze, generando un effetto valanga sull'intera distribuzione (es. pcmanfm lxpanel e sopratutto vari pacchetti ricavati di gnome).
   Per quelli, lavorando un po' su con delle patch, si riescono a mantenere inalterati, pur lavorando con librerie recenti. Su quelle patch ci ho speso molto tempo e se occorre (e siete d'accordo) posso anche provare a fornirle direttamente.
   Almeno questo è stato il mio metodo per avere una versione LFS 10 di slitaz a 64bit (reali). Altrimenti, causa legami con le dipendenze, seguendo le necessità dei sorgenti si generano più o meno dei sistemi operativi del tutto simili fra loro come accade in tante altre distribuzioni.

   Posted 2 years ago #
3. 

   shann
   

   offline

   Administrator

   Hi,

   Infact, graphics tests not revelant, just nice to see that work.
   goal it's to follow LFS 10 (maybe 11 if possible) for toolchain.

   Posted 2 years ago #
4. 

   shann
   

   offline

   Administrator

   Hi,

   New day :).

   I define target toolchain :
   - binutils 2.36.1
   - gcc 10.2.0 (mpfr 4.1.0, mpc 1.2.1, gmp 6.2.1)
   - glibc 2.19 (patch configure version to work mpfr 4.x and gcc > 9)
   - elfutils 0.183
   - elkfkickers 3.1
   - make 4.3
   - gc 8.0.4 required by gcc 10 [added]

   bump few and add 2 packages
   - check 0.14.0 required by kbd [added]
   - tzdata for locale [added]
   - patch cdrkit for gcc 10
   - bump kbd, libtirpc, perl (respectively 2.1.0, 1.3.2, 5.32.1) for gcc 10 compliance (multiple definition of function)

   Last step to switch on glibc 2.34, keep 2.19 at moment.

   

   Attachments

   1. undertaker_latest_cook.png (112.6 KB, 390 downloads) 2 years old
   2. undertaker_lastbuild.png (145.5 KB, 358 downloads) 2 years old

   Posted 2 years ago #
5. 

   shann
   

   offline

   Administrator

   Hi,

   I put new iso build after test upgrade packages with mass rebuild yesterday of cooklist (base + toolchain) and update current folder (both packages/wok) :
   https://people.slitaz.org/~shann/slitaz-4.0-stuff/slitaz-4.0-basedev-20220506.iso
   https://people.slitaz.org/~shann/slitaz-4.0-stuff/current

   new change bump kbd to 2.2.0 (issue with 2.1.0 [loadkeys scandir: No such file or directory])

   Posted 2 years ago #
6. 

   shann
   

   offline

   Administrator

   Hi,

   Begin stuff to rebuild final toolchain (follow LFS 10.1 for versions) :
   - binutils 2.36.1
   - gcc 10.2.0 (mpfr 4.1.0, mpc 1.2.1, gmp 6.2.1)
   - glibc 2.32
   - elfutils 0.183
   - elkfkickers 3.1
   - make 4.3

   I use kernel 3.16.55, target is to have lts kernel (4.x or 5.x), try to keep also 3.x version for old hardware requirement.

   first stage in progress, build temporary toolchain not depend of host.

   Posted 2 years ago #
7. 

   shann
   

   offline

   Administrator

   Hi,

   To ensure sanity of base / toolchain, i follow arch toolchain upgrade process.
   Due of rolling-release, toolchain rebuild each time of binutils / gcc / glibc new version.

   I already upgrade 2.13 > 2.19 (backward compat 100%), few fix/patch needed.
   bump to 2.20 and 2.21 sucessfull, remain 12 versions of glibc i continue and each time i check that base cli / toolchain work.

   After glibc 2.33, final toolchain it's ready, i go to next milestone "justx".

   I have new cooker "grell"
   undertaker > toolchain with glibc 2.19 and kernel 2.6.37
   grell > toolchain with glibc (2.21 at time) and kernel 3.16.55

   

   Attachments

   1. grell_last_cook.png (109.1 KB, 370 downloads) 2 years old
   2. grell_cooker.png (119.7 KB, 356 downloads) 2 years old

   Posted 2 years ago #
8. 

   shann
   

   offline

   Administrator

   Hi,

   I continue rebuild toolchain and mass rebuild of base with glibc version.

   I issue with glibc 2.24, failed when call /usr/bin/install, busybox complain usage.
   After check glibc 2.25 can be backward compat of 2.23, build this, update and rebuild toolchain again.

   Also notice 2 failed, openssl / perl, due usage of kernel64.
   For openssl, it's about 64-bit mode missing > fix with define 32bit target at configure step
   For perl, not really failed, just perl library use x86_64-linux name (/usr/lib/perl5/5.32.1/x86_64-linux) instead i686 > fix by define archname as i686-linux

   I step on mass rebuild with glibc 2.25 (remain 8 versions ;))

   Posted 2 years ago #
9. 

   shann
   

   offline

   Administrator

   Hi,

   continue upgrade glibc :
   - 2.26 ok
   - 2.27 issue about libc_pic.os, seem race condition with gcc, i skip them and switch to glibc 2.28 successfull (backward compat 2.10-2.18 and 2.22-2.28).

   busybox bump to 1.31.1

   at this step, i sync versions of base packages to follow LFS 10.1, mass rebuild in progress.
   - util-linux 2.36.1
   - gawk 5.1.0
   - readline 8.1
   - less 563
   - kmod 28
   - tar 1.34
   - glib 2.46.2 (not introduce ninja / meson for moment, glib 2.66 required them)
   (...)

   when this mass rebuild done and tests pass, i go to create new iso.

   Posted 2 years ago #
10. 

    enigma9o7
    

    offline

    Member

    This is exciting news. I'm looking forward to trying your new iso.

    I bet with all this new stuff, flatpak support may be possible.... but even if not, still awesome, can run current firefox and various appimages!

    Posted 2 years ago #
11. 

    devl547
    

    offline

    ~ # cook my_life

    Wow, great job, shann.
    So we gonna have a SliTaz 4.0 with upgraded toolchain and libs?

    I stopped contributing to the project a couple of years ago cause of outdated gcc/glibc/etc and being unable to compile latest software versions.

    Posted 2 years ago #
12. 

    shann
    

    offline

    Administrator

    Hi enigma9o7, devl547,

    For moment iso compose only base and toolchain stuff (167 packages)
    I need recompile kernel, infact vm host used 3.16.55 x64, but on chroot i use more recent linux-api-headers and glibc ;) (need to keep .config small as possible without enabled all new options).

    devl547, yes goal it's provide 4.0 with recent toolchain / libs.

    latest iso i provide slitaz-4.0-basedev-20220506.iso, it's base upon binutils 2.36.1 / gcc 10.2.0 / glibc 2.19.
    With backward compat of glibc, packages in 4.0 seem work, just for test ;).

    I follow LFS 10.1 packages version, goal it's to have binutils 2.36.1 / gcc 10.2.0 / glibc 2.33.
    this ugprade toolchain involves bump version (kernel > 3.2, few new deps).
    I very pay attention of new dependencies introduce (avoid dependency hell).

    This is my roadmap :

    Milestone 1 :
    base iso with new toolchain stuff work

    Milestone 2 :
    justx iso work
    => For this step, i hope that gtk and graphical stuff work without big bump need.

    Milestone 3 :
    gtkonly iso work

    Milestone 4 :
    core iso work

    Posted 2 years ago #
13. 

    shann
    

    offline

    Administrator

    I put iso with kernel 5.4.193-vm (minimal stuff only work on vm)
    https://people.slitaz.org/~shann/slitaz-4.0-stuff/slitaz-4.0-basedev-20220513.iso

    not finish for final toolchain, remain 5 releases to go on 2.33.
    For kernel i check to have 5.4 with 3.16 config

    Posted 2 years ago #
14. 

    alanyih
    

    offline

    Administrator

    Hi,

    Milestone 1 :
    base iso with new toolchain stuff work

    Milestone 2 :
    justx iso work

    Milestone 3 :
    gtkonly iso work

    Milestone 4 :
    core iso work

    Great!

    You are right.

    SliTaz style - KISS
    keep in simple and stupid

    Posted 2 years ago #
15. 

    shann
    

    offline

    Administrator

    Hi,

    I need to ensure sanity toolchain, when i try to build glibc 2.32 or 2.33, binutils broken and complain about more .h file 'WARNING: argz.h: present but cannot be compiled' and finish cook error with
    

    ./config.h:568:15: error: two or more data types in declaration specifiers
    ./config.h:571:17: error: two or more data types in declaration specifiers

    broken gcc second pass also.

    Posted 2 years ago #

RSS feed for this topic

Reply »

You must log in to post.