SliTaz Forum
You are not logged in.
I haven't been here for a little while, & I was wondering how SliTaz version 5 is coming along, (or not).
Is there any recent activity ?
Just in package updates and a few fixes to cooking. No official news on a SliTaz 5 release, although there have been several people that have been trying to push for a release.
Offline
Thanks for the info Trixar_za - I did grab a cooking dvd a few weeks ago.
> Is there any recent activity ?
... tons of it! Have a look here: http://hg.slitaz.org/?sort=lastchange
But I'm also wondering what technical reasons there are for the delay of a SliTaz 5 release? Except for the muddled boot options screen and the problems with udevil/SpaceFM, all the Rolling releases of the past 6+ months have been working without a hitch on my hardware. A while back Kultex has posted an ISO image with a tweaked kernel, which also worked without any problems. So, what's holding back 5.0? I read the debate in this forum and on the mailing list fairly regularly. Have I missed anything?
And now people are discussing a backport repo to give SliTaz 4 another lease of life. I think this is only a good idea and worth the effort if a SliTaz 5.0 release is indeed not even on the horizon. But is it?
Offline
There are several things that need to happen before we can release SliTaz 5. The first is that we need to create a package repository (split off current cooking) for it and then release a release candidate of SliTaz 5 configured to use it. The second step is to get people to test it and draw in developers to fix the bugs the testers identifies. After enough bugs have been fixed, we can release a second RC version for further testing and a second round of bug fixes. Once that's done and all the critical bugs have been fixed, we can finally release SliTaz 5 completely.
So, do we have any takers that want to get the ball rolling on this?
Offline
>So, do we have any takers that want to get the ball rolling on this?
Do we have enough developers to fix all bugs found? Some bugs are a couple year old :3
Offline
True. The only way a release will happen is if we pull some people into the project. Testers can be debuggers too, so it just needs somebody with repository commit access to apply it. I also think we should create a debug page just for testing SliTaz 5 RC, so we don't try fixing old bugs that aren't there anymore. I haven't really contributed much, so I'm willing to put in some debugging work once this gets started.
Offline
hi,
seems that these would be the main characteristics of SliTaz-5
* Binutils 2.23.1
* Linux API headers 3.2.40
* GCC 4.6.3
* Glibc 2.14.1
can anyone confirm?
Offline
Confirmed, although each one probably needs to be upgraded.
Offline
Les nouvelles versions attirent souvent de nouveaux développeurs.
Je suis d'accord avec Trixar_za pour la page de debug.
La vraie question est: la rolling est-elle suffisamment stable pour en faire un cooking ?
===
New versions often attract new developers.
I agree with Trixar_za for the debug page.
The real question is: the rolling is stable enough to make a cooking?
Offline
yes it is stable enough - I am running now my testing iso since more than 3 month without any problems
the only bug for me is in claws mail
before we make a RC1 I suggest following things:
Update:
claws-mail to 3.9.2 - is now 3.8.1
spacefm to 0.9.2 - is now 0.8.6
udevil to 0.4.3 - is now 0.4.0
wbar to 2.3.4 - is now 1.3.3
midori to 0.5.6-1 - is now 0.5.0
change the kernel config - I will look one more time into it and attach it the next days
it would be nice, if somebody can do it, as I have no hg access
EDIT: kernel is now 3.2.53 - I will look, if we need some more changes
Thomas
Offline
>although each one probably needs to be upgraded.
IMHO, we dont have enough people to work on both stable and rolling versions.
We are not debian or ubuntu, we dont need to mess with LTS versions. Why not keep everything updated to latest versions?
Offline
No. We don't have enough people and time.
The last cooking was published in 05/2011. In the past, before publishing some RCs, we used to do more cooking.
I think we must plublish at least one Cooking before starting RCs.
Updating some packages ? Why not if it does not break anything. In particular udevil and Midori.
@Kultex: Touch the kernel and toolchain involves too much change.
What changes have you made to the kernel configuration?
And we also have some packages to fix on the build host (http://cook.slitaz.org/)
Offline
@erjo
kernel issues are discussed starting from here
http://forum.slitaz.org/topic/notes-to-new-cooking/page/8
mainly I touched ide and scsi
if we would stay on the rolling kernel, there would be no ide CDs and DVDs as udev does not handle any more the old ide config and I included better scsi support (this effects only the linux-scsi.tazpkg) and some performance issues
the kernel works perfect - you can test it from here:
http://forum.slitaz.org/topic/testing-iso-with-kernel-3250
Offline
kultex: You may have to provide your udevil and sd[a-z][0-9] supported slitaz scripts.
Offline
no scripts - its just the different kernel config
Offline
Oh right, I'm thinking mdev configuration. Since we don't use it, we don't really need to write in support. I'm pretty sure udevil does a better job at managing this.
Offline
@ erjo: I think we should go with tom's (kultex) ideas, I had to add sleep 1 to system.h to get rolling to boot (although it looks like the soundcard stuff has been commented out now). I can mount all my drives (inc. usb) no problem with the new kernel config, and sound and video (nouveau) drivers working fine also. I don't have wifi unfortunately.
If we could use an updated kernel and packages that would be great also.
Having a spacefm-root desktop file and wbar is a nice touch.
Offline
== Google Tranlate ===
I have nothing against having kernel and package updated. On the contrary!
Each new version of SliTaz, I spend my time compiling everything to have the latest version of my favorite applications.
This is also why I support the idea of backports (http://forum.slitaz.org/topic/survey-for-create-backport-repository-for-stable-release). The most part of utiilisateurs, myself, do not even know what version of glibc they use. They just want to have the latest version of claws-mail, Firefox, Apache or other packages.
What I want to avoid is to destroy everything and start with 1 or 2 years of debugging.
I do not doubt the work Kultex and Tom made. But our buildhost is sometimes capricious with some change
== French ==
Je n'ai rien contre le fait d'avoir des paquets et un noyau à jour. Au contraire!
A chaque nouvelle version de SliTaz, je passe mon temps à tout recompiler pour avoir des version plus récentes de mes applications préférées.
C'est aussi pour ça que je soutiens l'idée du backports (http://forum.slitaz.org/topic/survey-for-create-backport-repository-for-stable-release).
La pluspart des utiilisateurs, moi le premier, ne savent même pas quelle version de glibc ou de toolchain ils utilisent. Ils veulent avoir la dernière version de claws-mail, Firefox, Apache ou autre packages.
Ce que je veux éviter, c'est de tout casser et repartir avec 1 ou 2 ans de deboggage.
Je ne mets pas en doute le travail que Kultex et Tom ont réalisés. Mais notre buildhost est parfois capricieux avec certains changement...
Offline
tout à fait, et ce que je vois c'est que présentement avec la rolling, mon écran externe
est bloqué à la même résolution que l'écran de mon laptop... donc c'est super d'être toujours
à la pointe, mais le résultat est que je connais maintenant une flopée de gens qui sont passé
à côté de Slitaz parce qu'ils ont du faire face à 2,3 écrans noirs et cette idiotie d'avoir à get-installer
le module ethernet ou wifi
Franchement, vous avez le mérite d'avoir construit un des meilleurs linux par la pureté de son code, mais
est ce que c'est bien nécessaire d'avoir des milliers de paquets qui sont utilisés par 10% des gens alors
que ça vous prend peut-être 90% de votre temps pour les compiler ou je ne sais pas trop quoi ?
@Paul - you had to add sleep=1 in my testing iso? - in my iso you will find the soundcard stuff and all my other changes in local.sh
@erjo - I underline your statment, that we have to avoid to destroy everything and start with 1 or 2 years of debugging. Thats the reason, why I want to stay on kernel 3.2.xx and never would touch glibc....
Offline
Well, we'll stay with 3.2.x for now and once a full release happens, we can backport newer packages while updating the cooking repository. This seems like the simplest way.
@erjo - Can you make a backports repository on hg.slitaz.org ?
Offline
@ kultex: I only added sleep 1 to the 'official' rolling (I hacked a LiveCD). Your iso boots fine for me.
Offline
ok, it seems now, that we are going for 5.0
before we start to do this, somebody has to take care of cookutils - also Kapil describes here http://forum.slitaz.org/topic/chroot/page/3, that something does not work
I tried to configure evrything new today, but I could not cook, because of missing depency busybox-boot 1.21.1 - I see on http://pkgs.slitaz.org/search.sh?receipt=busybox&version=cooking, that busybox is 1.21.1, in wok its 1.18, but I dont know how to update wok.
I really think the same as Kapil, that it would be good, if somebody makes a working cookutils iso, where it is easy for beginners to learn and help and not to struggle around setting it up - its such a loss of energy and I think also a loss of people
Offline
update wok ?
Clone a repo, example for wok
$ hg clone http://repos.slitaz.org/wok
To update your wok with the local server
$ hg pull -u
Offline
[ Generated in 0.018 seconds, 7 queries executed - Memory usage: 1.58 MiB (Peak: 1.77 MiB) ]