SliTaz Forum
You are not logged in.
Looks like the only way to have the message been read and discussed by all slitaz devs is to write it here on our forum.
Guys, we strongly need toolchain updates (gcc, glibc, other support libraries).
Some packages even fail to compile with our in-repo versions (like fresh webkit or llvm).
After discussing with Alexey and sharing our developer problems, we both agree on that topic.
Currently I have working builds of gcc 4.9.2 and latest glibc (2.21). Maybe it's time to put them in the wok?
SliTaz is not only a LiveCD, it deserves to be modern desktop distro.
Offline
Years ago SliTaz did have divers clearely recognizable tool chains in the old depots. If you tipe today
$ tazpkg -lm > allpkg
or using TazPanel > Packages >> Categories development >>> search "toolchain"
you find
buildroot and
slitaz-toolchain.
is that the actual tool equipment of SliTaz
(pls I repeat my request to open a subdiv widmed to the build of SliTaz in that forum: a lot of persons can not be uptodate concerning that hidden knowledge and need like devl547 did explain it point to interchange knowlegde, hints and opinions! my goal is different from goal of that "devel" subdivision of the forum : I do not pretend to want to become a developer but only to build myself and for my processor the system I am using and I find there are two completely different goals. I hope to find and meet in such a subvision other people wishing to do the same thing and only that)
Offline
Offline
"... the toolchain gets a huge update once a year just after a stable release" and since there hasn't been a new stable release for almost 3 years ...
used: gcc 4.6.3 (2012-03-01)
latest: gcc 4.9.2 (2014-10-30)
used: glibc 2.14.1 (2011-10-07)
latest: glibc 2.21 (2015-02-06)
used: binutils 2.25 (up to date)
Offline
mojo, it's useless to write in a DEAD mailing list.
ALSO:
PACKAGE="slitaz-toolchain"
VERSION="5.0"
Up: slitaz-toolchain (5.0) This will rebuild all toolchain, each pkg already build sucefful on tank
author Christophe Lincoln <pankso@slitaz.org>
date Fri Apr 13 02:16:05 2012 +0200 (2012-04-13 ago)
Almost 3 years have passed.
Offline
you can of course operate with the fresh new tools of LFS offered by NuTyx, an other distro with Swiss origin, offering for developpers an ideal chroot environment to package...
...according the needs of
NuTyx,
not of SliTaz (NuTyx is exactly the opposite of SliTaz: to much changes to already have the most new version of LFS in all fields and development tools... both are bad: SliTaz not enough / NuTyx to much... The world is not perfect at all!)
Offline
I just repeat my point of view as a user...
updating toolchain is too dangerous. Evrythink works fine on old hardware ....
but its time to finish 5.0 - the "main" thing to be done for me is "tazhw setup printer"..... and I agree with you, that after 3 years it would be necessary to make a change..
but this should be done as 6.0 - just to remember, Pankso also started 5.0 before 4.0 was ready.
And I think, that this is the main question - is there anybody exept Pankso to make decisions.
Eric - Paul - Pascal - whats your oppinion about the future? For Pankso it seams only possible to work like mad or to be totally absent.
I think, the main question is to find the way, who is taking responsibility, when Pankso is absent and not if the toolchain needs an update.
Offline
We can't expect one man or a handful of developers to do everything.
Essentially that's what it boils down to with the lack of access, responsibilty dodging (of which I'm also guilty - probably more so than most), resistance to change and dated packages.
We need a way around this and I think the easiest solution would be to mirror the hg repositories on bitbucket and github. This instantly .gives us the eyes on millions of developers and makes it possible for the average user to contribute while the head developers can review changes before accepting them. This could potentially fix 3 out of the 4 issues we're having right now.
The next step is to stop this resistance and fighting against any change. SliTaz 5 is in development and as such needs to be constantly updated with the latest changes we can provide. It's because we've been fighting changes that we're stuck where we are now, although we call could see it coming since SliTaz 3.
That said - I think we should update everything related to creating a stable distro. That being the build tools, the kernel, busybox, xorg, gtk, lxde, alsa, syslinux and everything else I forgot to mention. Once we've updated and rebuilt the essentials, we can focus on fixing the packages that the changes broke. After that we can focus on updating packages that worked regardless.
The end result would be a way more open and up to date micro-linux. I think that would be worth the minor trouble it will cause now.
Offline
@Trixar: I fear that "fixing the packages that the changes broke" might be more than a "minor trouble".
@devs in general: If you can't resist the temptation of breaking everything ;-) before releasing 5.0, maybe you could first release RC3, then work on upgrading everything bottom-up.
Offline
I'd rather break and fix it now than leave it in it's current semi-broken or outdated state. Experience also taught me that only a handful of packages will break, but only because they either require the latest libraries or a specific version of them - either case it's bad programming that's at fault. Inclusion of those libraries would be minor considering the damage we're causing trying to stick to older and broken versions of things.
I also don't see the point of releasing a 3 year out of date distro because a version got delayed that long. That would kill SliTaz's standing for sure.
Offline
>who is taking responsibility, when Pankso is absent
All of us. SliTaz is not one-man project. We all work on it, so our collective decision is needed.
>Evrythink works fine on old hardware ....
when SliTaz became a distro only for outdated hardware?
Offline
I see no reason not to update the toolchain, especially when taking into consideration the amount of modern software that has been pushed to the repository.
As long as it works for both dated and low-power hardware, I have absolutely no issue with it, even though it isn't up to me.
Offline
@devl547
Slitaz isn't a distro only for old hardware, but I use it because it works on my old hardware. That's the reason I use Slitaz. If the distro stops working on old hardwares, many people will stop using it.
Although Slitaz is very fast, I don't know a single person that bought a brand new PC and installed Slitaz on it; many users prefer to use Mint, Debian, Ubuntu, etc, etc... That is, (really) big distros that doesn't work on a 4-5 year-old PC (or older).
It would be nice if Slitaz could maintain the compatibility with old hardware, and also work on new hardwares.
That's my humble opinion. ;D
Offline
Je vais répondre en français car c'est ma langue maternelle et que le sujet me semble important. La traduction en anglais vient de Google translate .
Je trouve que chacun à un point de vue qui se défend.
Oui, Slitaz est un projet communautaire. On ne doit pas se sentir perdu parce que Pankso n'est pas là pour l'instant. Ce n'est pas forcement à lui de tout faire.
Non, slitaz n'est pas dédié au matériel obsolète. Mais c'est aussi le fait de pouvoir faire revivre de vieux PC qui a contribué à notre succès.
Il ne faut pas l'oublier et laisser tomber les utilisateurs qui ont des vieux PC.
Mais j'aimerai moi aussi pouvoir utiliser correctement Slitaz sur mon nouveau portable Asus ou sur un serveur HP avec un control RAID et plus de 64Go pour faire de la virtualisation.
Oui, il faut surement réflechir à une nouvelle façon de travailler. Pour éviter des cycles de développement aussi long et faciliter la venue de nouveaux contributeurs.
Oui, 3 ans c'est long, trop long.
Mais je ne suis pas certain qu'il suffise de mettre à jour GCC et Glibc dans le Wok pour que ça fonctionne. Il faut surement recompiler la toolchain, recontruire l'environnement de build etc.
C'est vrai que publier une distribution avec une toolchain qui date de 3 ans ce n'est pas ce qui'il y a de mieux. Mais repartir sur un nouveau cycle de 3 ans parceque l'on aura tout cassé et que l'on n'a pas 100% de notre temps pour travailer dessus ne m'inspire pas beaucoup. J'ai gardé un assez mauvais souvenir de mises à jour faites au dernier moment lors du passage à la version 4.
Beaucoup de nos problèmes viennent aussi de sources buggés ou de librairies mal packagées.
Pascal à terminé recompiler tout les paquets pour que l'on puisse faire une RC3 avec les dernières mises à jours de librairies publiées dans le wok. Il reste kuste 7 paquets à corriger.
Je pense que l'on peut peut-être couper la poire en 2 (si c'est possible)
- Dupliquer l'environnement de build (chroot and wok) pour mettre à jour la toolchain.
- Publier rapidement la RC3 et la version 5 pour ceux qui en ont besoin.
==== Google translate =====
I will answer in French because this is my first language and the subject seems important. The English translation comes from Google translate.
I think that everyone has a point of view that defends.
Yes, SliTaz is a community project. We should not feel lost because Pankso is not there now. This is not necessarily for him to do everything.
No, slitaz is not dedicated to obsolete equipment. But it's also being able to revive old PC that has contributed to our success.
We must not forget and drop users who have old PC.
But I love me too to properly use SliTaz on my new Asus laptop or a HP server with a RAID control and 64GB for virtualization.
Yes, we must surely think about a new way of working. To avoid such long development cycles and facilitating the entry of new contributors.
Yes, three years is a long, too long.
But I'm not sure it is enough to update GCC and Glibc in Wok for it to work. It must surely rebuild the toolchain, recontruire environmental build etc.
It is true that post distribution with a toolchain that date 3 years this is not what has qui'il better there. But again on a new 3 year cycle becaufe we have all broken and that one does not have 100% of our time to travailer above does not inspire me much. I kept a very bad memory upgrades made at the last moment during the transition to version 4.
Many of our problems also come from sources buggy or poorly packaged libraries.
Pascal finished recompile all packets so that we can make a RC3 with the latest updates libraries published in the wok. It remains Kuste 7 packages to correct.
I think maybe we can split the 2 (if possible)
- Duplicate build environment (chroot and wok) to update the toolchain.
- Quickly Publish RC3 and version 5 for those in need.
Offline
Erjo, I totally agree with you, and as a user I second your proposal.
Offline
Salut,
Erjo, je suis entièrement d'accord avec ton idée.
Ce qui à fait que j'ai découvert SliTaz, c'est justement sa capacité à tourner sur de vieux coucou, tout en gardant une certaine "fraicheur" en terme de logiciels.
Il faut donc comme tu le suggère garder cette compatibilité mais également en parallèle faire une release qui soit à même de supporter le matériel récent.
Oui, cela va certainement demander une bonne charge de travail, pour ma part je suis prêt à donner de mon temps.
Il serait dommage que SliTaz ne soit considérer que comme un OS pour anciennes machines.
=========
English translate (with google Trad)
Hi,
Erjo, I completely agree with your idea.
Which in fact I discovered SliTaz is precisely its ability to run on old hardware, while keeping a certain "coolness" in terms of software.
So be as you suggest keeping this compatibility, but also in parallel to a release that is capable of supporting the latest hardware.
Yes, this will certainly ask for a good workload, for my part I am willing to give my time.
It would be unfortunate SliTaz not consider that as an OS for old hardware.
Offline
Human translation of shann's last sentence:
"It would be a pity that SliTaz be considered only as an OS for old hardware."
Offline
>"It would be a pity that SliTaz be considered only as an OS for old hardware."
Sure. There are lots of new, but underpowered devices like low-end laptops and desktops
They need lightweight system, but also new kernel for hardware support (like my amd athlon 5350 apu).
Offline
You do know that we can have more than one kernel version in the repository and flavors, right?
Holding on to the old kernel just for old hardware is unwise and a newer toolchain won't make much of a difference for older hardware compatibility anyway. Puppy does this already.
Also this is my point. We're always doing this. Somebody comes up with a random point like 'SliTaz should work on old hardware, so we shouldn't use a new toolchain and kernel' and people agree to the point that halts or hamper development.
Two questions should come with any statement like that:
1) How do you know the new kernel and toolchain won't work for it? Other Linuxes don't count since they alter more than just the toolchain and kernel that breaks older hardware compatibility.
2) Why can't we just make two versions in the case it doesn't? Puppy does this already with general packages that work on all versions - why can't we do the same?
Offline
A new toolchian means 5-10% broken packages. (ie 200-500 packages to fix)
Who will fix them ?
Offline
@ Bellard & Erjo
I agree with both of you - is it possible to realize Erjos proposal to duplicate chroot and wok and name it like wok-6.0 quick? As possible name for the isos I propose experimental....
So devl547 and Trixar_za can start to change kernel and toolchain
Who is able to do that?
@Trixar_za - with 4.0 we lost 486 and 586 compatibility with the kernel update and nobody tells, that it will be with a new kernel, but I just mentioned that this is dangerous and a lot of linuxes dont work on my old - non i686 machines....
Offline
>on my old - non i686 machines....
>Yet another change for the upcoming Linux 3.8 kernel is the removal of support for the old Intel i386 processors.
AFAIK, all Pentium-based and later PCs still work.
>Who is able to do that?
I can push gcc and glibc updates, cause I already use them on my computer.
As for kernel - I dont understand our current receipt split, so that job is not for me.
>A new toolchian means 5-10% broken packages.
Think of it as "5-10% of our packages somehow work, but not as intended".
But man, even heavily modified gentoo systems work with no problems after glibc or gcc updates.
>Who will fix them ?
Write me on top of that list)
Offline
>Write me on top of that list)
Great! Let's start with http://cook.slitaz.org/#broken
for example http://cook.slitaz.org/cooker.cgi?pkg=blender
Offline
I'd do it too. Btw those currently broken packages are that way because our libraries and toolchain are out of date. So you kind of proved my point.
We're also up to i486 if memory serves, but even going to i686 won't really break support. That's like the early Pentium II and I doubt anybody will try running SliTaz on anything older than that.
Offline
> with 4.0 we 486 and 586 compatibility with the kernel update
Really? So we may change gcc "arch" to "686", or at least "tune" to "generic" if this is wrong information and only 386 compatibility was lost. We have:
- kernel config looks like optimized for 386 (even with CONFIG_X86_CMPXCHG is not set, but I'm not sure: maybe CONFIG_CMPXCHG_DOUBLE=y "did the trick")
- packages still optimized for 486: without usual [c]mtune=generic[/c] - it's 486-compatible option (first of all for gcc), which is critical for performance exactly on old hardware). I think it is necessary to consider while next recookall/toolchain updates.
> Btw those currently broken packages are that way because our libraries and toolchain are out of date
Only kernel&glibc are out of date. Some packages was broken because of too new libs: such as glib from unstable branch.
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]