SliTaz Forum
You are not logged in.
Hi there,
I want to upgrade toolchain. In fact, what we use now, it has long been out of date.
Together with this update SliTaz-5.0 is coming to the End-of-Life.
Here you can ask me: “What? Which SliTaz-5.0?”. Unreleased one.
We released RC-1 to RC-3, but never released the 5.0.
Maybe this is due to great responsibility. Maybe it would be desirable to make a perfect release…
There is nothing perfect.
While we have not released, we can not start the next round of updates, as it was before.
Major distributions offer update once or twice a year.
We also could produce releases twice a year, calling them, for example, SliTaz-2016-5 and SliTaz-2016-11 or something like that. When it's time to release, we just save current Rolling with the release name. And then, maybe once a two years, or once a year to update the entire base…
As a result, today we stopped with the old toolchain in Rolling Flavor, and with ancient — in the stable version. What does it take to release 5.0? We can just call our recent build the name 5.0.
But today I wanted to talk not about the release. Regardless of whether or not to release, the need to update overdue and the question is relevant. (I know that some old packages will stop to compile with the update. Therefore, the release still needs to be done to keep all the packages available in the work, although in the old state.)
After the upgrade, we will get access to many interesting programs, such as, for example, LXQt, based on Qt5.
* * *
So, I informed you of my intention. How do I do — is another matter 
Unfortunately, I never had to deal with the updating of the basic packages. I had enough of what has already been done by others. I do not have any experience in this.
When I could not “just” update packages, I began to look closely to the LFS. While I was not able to go far. I updated Binutils without problems. But I'm stuck on the compiling of GCC.
I try to update SliTaz receipts in accordance with the steps outlined in LFS. Just want to say the following. Receipts “extension” for cross-compilation had to throw. It is difficult to maintain the usual receipts with more updates. It is doubly difficult to maintain the “double” receipts for regular compilation and cross compilation. Unable to maintain cross-compilation, because I've not addressed.
I know that in order to make excellent packages a single LFS is not enough, need tips from other places…
I will be glad of any help in updating the base system. And I will be very happy when we all come together — old and new SliTaz developers! United with one interesting case…
Offline
Hi Aleksej,
It is legitim as you did explain it now. But. please, give as a complete copy (big iso binaries + big iso sources) of the last stage of the never published (::) SliTaz 5.0 so user have developed her particular environment can continue stand alone at home ;-) . Thank you for your announce and thank you for that taking in consideration for user having to continue a certain time her way as beginned. And good luck for SliTaz 6.0 (I see that my wish to make it self compiled and self compiling is not for 6.0 but perhaps better to obtain with a new tool chain).
Kind regards
Note: it would be good to find all concerning Slitaz chains unter SliTaz-pipapo or Taz-pipapo so that you can find them all ;-) easily invoquing tazpkg -l at an central place in the names list... And a short comment would permit to overview which chains are present and what they does (eventually also which "subcbains" they are containing...)
Offline
It's been talked about since long, and now it's happening. At last! But I have some questions regarding what's going to happen to 5.0. I have read your text carefully twice and found that you've been rather vague about this.
- Is 5.0 just going to be dumped and left in its current state?
- If, for whatever reason an 'official' final release can't be made, won't there be at least some sort of 'internal' final release like e.g. a RC4? After all the work that went into it, I think this is the least one would expect.
- Why have the two latest rolling releases been 10 MB larger than all the previous ones? They used to be 42 MB, now they are 52 MB.
- The value of /etc/slitaz-release should be the same across all boot options. Currently it is like this ...
[c]
SliTaz core Live : 5.0
SliTaz gtkonly Live: cooking
SliTaz justx Live : cooking
[/c]
... and I think that in a final release they should all be '5.0', so one can use them in scripts without any hassle.
> How do I do — is another matter
I hope you're happy and you are doing fine!
Offline
Hi oui,
I think we don't need the big ISO with all the packages.
We can "put to a museum" SliTaz-4.0 in the role of SliTaz-Stable, and to release current SliTaz-Rolling under name SliTaz-5.0 and also known as new SliTaz-Stable. So, all the current Rolling packages will be available in the renewed Stable repository. (And SliTaz-4.0 will be the history...)
What you mean with the "SliTaz-pipapo"? I search it across SliTaz packages, and across the Internet, but found nothing relevant 
Is it just mean "miscellaneous", "tutti frutti", etc.?
Offline
Hi Darjeeling,
Yes I was not clear what to do with the SliTaz-5.0.
I started the topic in the hope that someone was more lucky with the toolchain update, and that he can do it more quickly than me.
Guys, thank you both for you with SliTaz!
As we stated it before, “any help is appreciated”.
Have a nice day!
Offline
I agree with "pass 4.0 to the museum and rename current Rolling as Stable 5.0." and start 6.0
Offline
I hope this... If SliTaz 5.0 stable could not be, not decay, better times will come ... Maybe it's correct Rolling spend as stable and start again with new toolchain looking at a SliTaz 6.0 on the horizon
Offline
Hi Aleksej
pipapo is on French a "open place holder" for each possible extension like
tazx
here is "x" the pipapo...
greetings
Offline
Thank you, oui.
I think I understand you now. It is something like ”bla-bla-bla“ in the English
Is it looks like about you're asking? --
http://pkgs.slitaz.org/?package=taz
Offline
@Aleksej : You develop a great job on the Slitaz team. All developers are special. Today the Rolling is too full of fantastic features and functional. I don't see problems in new versions, I prefer stable and functional versions that work with security. Yes, problems may arise, but there is our forum to resolve issues in the future.
I am very happy with Slitaz Rolling is perfect on my computer with all features running without errors. Congratulations on your work.
Offline
Leonardo, thank you for kind words.
I only wanted to note for all of you guys, that my work on the SliTaz is not so big, as you sometimes stated here on the forum. Please, don't make me feel myself uncomfortable.
Our real great heroes are @Pankso and @Bellard. Just take a look here:
http://pkgs.slitaz.org/?maintainer=
and there:
http://hg.slitaz.org/
Offline
What are the toolchain difficulties at the moment?
...
Please, do not feel uncomfortable. We are all a big seed for the garden of life. "... All developers are special ..." 
Offline
@Aleksej
> gcc
"gcc49" package already present in repo to compile C++11 code (such as qt5). I think it will be impossible to rebuild all packages with new gcc, we'll get largest amount of "broken packages" ever, gcc5 is just broken inside.
> glibc
Maybe it have to be updated immediately, without any "next" or "toolchain update". Every day more and more precompiled binaries requres newer version.
kernel
Since 4.3 it doesn't work with intel-video and a lot of other regressions.
glib
It's not part of toochain, but I just have to note, that freezing repos with dev-version of glib is bad idea.
@Darjeeling
> Why have the two latest rolling releases been 10 MB larger than all the previous ones?
Gstreamer is now installed by default - allows for example youtube in tazweb without flash. I don't know why it was added to core.
Offline
2 az_ua
> gcc
"gcc49" package already present in repo to compile C++11 code (such as qt5).
It is just great.
I think it will be impossible to rebuild all packages with new gcc, we'll get largest amount of "broken packages" ever
I know it.
Old packages like "notecase", unmaintained too years ago, back in the 2008, needs to be patched again and again up to you just give up, because you are not an author of that piece of code. I doubt we can save all the packages during system update.
gcc5 is just broken inside.
Pretty bold statement. However, I'm not expert.
LFS and BLFS are the books with the ready-to-use receipts how to prepare modern Linux system.
And they are based on the GCC-5.2. I doubt that they could achieve this success by using a broken compiler.
On the other hand, GCC — it's just a compiler. It compiles the code.
If it will be sufficient to use the existing compiler, so let's try to use it.
I am confused by only one thing.
I think that some of the packages described in the LFS/BLFS book require patching, also described in the book. Using a different compiler, we can not just follow the described instructions and will not be able to use the proposed patches. We have to go our own way. I am afraid that it may take a very long time: searching the internet, patching... We have very humble human resources to deal with this.
> glibc
Maybe it have to be updated immediately, without any "next" or "toolchain update". Every day more and more precompiled binaries requres newer version.
Heh
Glibc IS part of toolchain. Updating the part of toolchain IS updating toolchain.
Note, EVERY, literally every package, that contains executable binary or shared library is depends on Glibc. So, we need to rebuild them all. Will it be possible to “save” all the packages after the upgrade Glibc?
What is your opinion about the Glibc version 2.22?
If I understand correctly it is enough to update our Glibc-2.14.1 to Glibc-2.15 for modern applications such as Maxthon web browser. But still, LFS uses Glibc-2.22, and I see no reasons to not follow them.
kernel
Since 4.3 it doesn't work with intel-video and a lot of other regressions.
We can stick with the current used Linux Kernel 3.2. It is LTS and will be supported until to April 2017.
glib
It's not part of toochain, but I just have to note, that freezing repos with dev-version of glib is bad idea.
And your solution?
I remember to update Glib is completely painless, we can move on to a newer or older non-dev-version of Glib. To which one?
Offline
@az_ua
> Gstreamer is now installed by default
I hadn't noticed it. Thanks for your reply.
Offline
I'm afraid there are no choice except using two versions of gcc in a same time, just because it's easy way. I'm not expert too, but read that gcc developers completely rewrites its code, see a lot of bad feedback about gcc5, see files likes "gcc5.patch" for latest versions of almost all packages in dev-repos of some distros.
> some of the packages described in the LFS/BLFS book require patching, also described in the book.
> will not be able to use the proposed patches
Guess we can use every patch except "gcc5.patch". Some patches may be not described in the book, you can see it in git of every "fat" distro.
> Will it be possible to “save” all the packages after the upgrade Glibc?
Now we have not only humble human resources, but unsufficient machine resources too. In theory: we can disable pushing to mirror, upgrade, recookall, downgrade in case of bad result. Or build toolchain in chroot, copy wok to chroot, recook all. Now we know number of packages broken by update. But look on our build host: no enough disk space, "intel atom" instead of CPU, so it's just theory.
> What is your opinion about the Glibc version 2.22?
It needs patch for 32-bit build. And it's our main, in fact - only one SliTaz arch. If it's impossible to build glibc without patch, how it will work on it? Anyway let newer glib be highest priopity task. I'll try to build it, and test how it works with old gcc463.
> 2.15
There was some critical bug exactly in 2.15.(Or 2.13? read this about two years ago, not here, lazy to find it again.)
> I remember to update Glib is completely painless, we can move on to a newer or older non-dev-version of Glib. To which one?
2.44.1 should not broke something if its devs don't lies in changelogs.
> We can stick with the current used Linux Kernel 3.2
Agreed, my hardware are old too, so works fine with 3.2
In general: just decide to risk or not to risk...Why are you not using "undigest"?
I can't feel more skills than you, but will try to fix broken "if something".
Offline
Hi everybody!
Well, I think it's a good idea to make current rolling version as the "5.0 Stable" and start with new Slitaz 6.0. It will also update the "current version" at Distrowatch website. (information about Slitaz there is too old)
My hardware is old too, and it has a Intel onboard video driver. If we update kernel, probably Slitaz would stop working at my computer. So, if possible, let's maintain 3.2 kernel. All functions work smoothly here with 3.2 kernel.
Offline
"Why are you not using "undigest"?"
Because it is time to make decisions - 5.0 is out and stable and we have to set up a new cooking - now after 1 year of discussion after RC3. There is one more year left of kernel suppurt for 3.2 Kernel - and we need at least one year to have a new working cooking - I guess?
I think we should start with kernel 4.1 as it is LTS and then maybe switch to 4.4 the next LTS, which will be the next Ubuntu LTS kernel. - why I will explain tomorrow
Offline
There is no risk if slitaz-next is not developed in existing cook/5.0 wok as az_ua points out.
The proper way to develop updated toolchain and packages for slitaz-next is in a new repo cloned from cooking wok.
Bellard would set this up on tank if you ask him.
Offline
Hi!
According to Kernel.org the kernel version with the longest support is 3.2 (May 2018), even longer than 4.1 and 4.4.
Offline
First - super they prolonged 3.2 to May 2018 - in wikipedia there is still the old date!
Then my thoughts about new cooking - what can be the aim? For me most interesting aim is new Intel Atom devices - Bay Trail + Cherry Trail. Just to give you an impression, how powerful they are...
CPU Marks:
Intel Atom x7-Z8700....1971.........[Dual CPU] Intel Xeon 3.73GHz.....1940
Intel Atom x5-Z8500....1776.........Intel Core2 Duo T9400...................1772
Intel Atom Z3735F..........908.........AMD Athlon X2 Dual Core 6850e.....889
Bay Trail Cpus are on Tablets + Notebooks - Cherry Trails are until now only on Tablets
very often they have very limited HD-space and max 2GB of Ram and they are quite cheap - so they are perfect for SliTaz
But they are until now very hard for Linux - until now no linux support for Cherry Trail and slowly there is support for Bay Trail
The only linux distribution, which seems to work proper on Bay Trail until now is Gallium Os
https://ci.galliumos.org/job/GalliumOS-Nightlies/lastSuccessfulBuild/
and limited specialized on Intel Atom Sticks Linuxium https://plus.google.com/+IanMORRISON
Gallium OS is on Kernel 4.1.14 https://github.com/GalliumOS/linux/blob/master/.config
so I think, this is a good example to start with
Offline
Hi,
I agree that you should not disrupt current 5.0 which is quite stable. Also, the current official "stable", which is 4.0, should not be overwritten. Aren't SliTaz servers running 4.0?
If this doesn't break the tazpkg of 4.0, "stable" could be renamed "oldstable", to make room for 5.0 becoming "stable". But let's KISS: drop this Debian-like naming scheme, and just use the numbers (and drop this ".0" which is useless). Then on the homepage some text will explain which is considered "stable", receiving only patches, and which is considered "in development". There is a benefit of using numbers: at this time, if current cooking was released as ST5, and cooking was made to refer to the development of ST6, unsuspecting users currently running cooking/5 will end up with the unstable version if they launch "[c]tazpkg up[/c]", likely breaking something. On the other hand, by using only numbers, [c]/var/lib/tazpkg/mirror[/c] always points to the right repo.
However, before all these changes, I think there is a big TODO: update the doc website. The pages are often unclear about which version they address. We should separate what refers to 4 and what refers to 5. Otherwise, starting another version will turn the doc into a complete mess.
Also, cook.slitaz.org needs some inspection: some links are wrong, e.g. if you click the wok revision on http://cook.slitaz.org/stable/, you end up in wok instead of wok-stable. Again, using numbers would clarify things. cook.slitaz.org would have subdirs 4/, 5/, 6/... and hg.slitaz.org would have wok4, wok5, wok6...
As for the server power: are a new mobo, a new CPU, and new disks so expensive that we cannot buy them if we all put a little money? (By the way, who is physically hosting the server and paying the watts?)
To conclude, I'm sorry if there are too many "should" in this post. But I'm not expert enough to say "may" instead. I can translate pages, write and patch simple receipts, but issuing a release is far beyond my capabilities.
Offline
Very nice observations, llev!
About Slitaz Doc, I'm updating Portuguese Doc pages (when I have some free time) accoding to English pages. Reading the Doc, I saw pages with old (and possibly outdated) informations; some of them were edited in 2008 or 2010!
About Slitaz versions, we could use a simple scheme like this:
- Slitaz 4: named "Legacy";
- Slitaz 5: "Stable";
- Slitaz 6: "Rolling" or "Current".
Have a nice day!
Offline
First at all sorry for my very bad english, and second plane my opinion is not agree to rename the original distro on other.
These mode on italian are warning “not change the cards on table”.
One project, one name!.
Slitaz 5 not view to born. The project are stopped. Close it!
Rolling cooking not are significant distro. The people search simple new version of older. Or want to upgrade the current distro.
Or naming new project on sequential number, or naming new distro on new name.
I agree the way of construct new distro based on LFS, but seem these mode not are appreciated for most people.
It is all.
Offline
Hi all!
Seems I need to make some explanations to move forward.
Why I called topic “SliTaz next”?
It's time do develop next version of the SliTaz, version 6, because 5.0 is already outdated. But version 5.0 is not released yet. We talked here a lot of version 5.0 release, and I not wanted to open yet another topic regarding 5.0. I wanted to talk about near future of the SliTaz, about “SliTaz next”.
Why I mention LFS (Linux From Scratch)?
As for me, LFS is modern one. I don't know good and stable version numbers for packages. But I wanted to upgrade them. LFS offered versions, procedures and patches — so I don't need to make my own investigations and searches. Don't worry — we still use TazPkg receipts. LFS is only book with hints.
Why I proposed to name next version of SliTaz is 2016-*?
I think many people will be agree with me that we need SliTaz to be released. So many years we have been waiting for next SliTaz release! I think it will be a holiday! 
SliTaz Rolling already stable enough to become the next stable release. It contains some errors, and I know it. Nothing is perfect. We can endlessly to correct mistakes and improve. But we need release. I'm a developer, but did not have the releasing experience. I'm waiting for the developers who produced the previous version, will release the next one. Maybe they think that it is not good enough? In this case, the release schedule — once a year — would have decided the issue of perfectionism. In other hand, we can use minor version number too. We can release 5.0, and then 5.1 after some time like bug fixed, more stable version.
I do not propose to change the name of the project, or make of it some other project.
--------
So, what to do next?
First, about release. We always have ready-to-use weekly ISO. We test it periodically. And seems we can use it as next Stable at any time.
We need to write Release notes. Count commits since last Stable. Recall all the improvements… Then we need to translate Rel. notes to the SliTaz supported languages. Prepare web-site news page. Update Distrowatch project page.
Also we need to do some movements in the Mirror folders.
Second, about future update. I use separate chroot in the Tank mirror: [c]/home/slitaz/lfs/chroot[/c]. It is not automated at all (and I don't know how to do it): it not connected using [c]conspy[/c], and is not connected to the [c]cooker[/c] interface. It is only temporal solution. After that I update toolchain and some other base packages, I'll move upgrade process to the Undigest repository and will remove this chroot. I use it only because my netbook is too weak for compiling big packages and has low HD free space.
I plan to follow LFS, but with with adjustments, which we discussed above.
New toolchain GCC will be "gcc49".
I still unsure about Glibc version, I'll try to update it to 2.15 and to 2.22.
Linux Kernel will be still 3.2. It is good to support existing hardware. But I unsure about supporting of the new hardware Kultex talked about. Maybe we'll find a way to multi-kernel support (3.2 and one of 4.x) like today we have two Kernel branches: just Linux Kernel, and Linux-libre Kernel? I see that Kernel part called Linux-API-Headers is part of toolchain. And I unsure which packages strictly based on the Linux-API-Headers because it is always pre-installed is the cooking chroot, and some packages may use it while others not. I would be grateful if someone would explain it to me. Can we have multi-kernel, and which packages are based on the certain kernel version and should be multi- too?
Tomorrow will be empty.
And then I will have to come three days off, I'll take care of further development.
Stay in touch!
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]