SliTaz Forum
You are not logged in.
>Great! Let's start with http://cook.slitaz.org/#broken
>for example http://cook.slitaz.org/cooker.cgi?pkg=blender
As for blender - my fault)
As for other broken packages - llvm needs new gcc :3
> That's like the early Pentium II and I doubt anybody will try running SliTaz on anything older than that.
My slitaz test box used to be Pentium MMX 166 with 32mb of RAM. Pretty nice torrent box)
Offline
> That's like the early Pentium II and I doubt anybody will try running SliTaz on anything older than that.
1- My router / firewall / VPN end point / DNS-PXE is a P5-133 http://hardware.majix.org/computers/ibm.300gl/ running a live SliTaz ( and http://cook.slitaz.org/cooker.cgi?pkg=hardware-ibm-6272 )
2- Intel Quark is 486 or Pentium based
Offline
Evry Pentium is i686 - I run SliTaz on quite a lot of Futros A-250 with AMD Geode LX800 - i586
Offline
Kultex is right - i686 is Pentium Pro which also introduced PAE.
Of all the hardware mentioned, none fall under i486. Hence you gentleman just proved that moving to even the latest kernel (that removed i386 support) would make no difference to our support range.
glibc being out of date isn't a minor issue considering everything (including the kernel) is built against it. Same applies to anything built against the kernel - mainly drivers needed to make devices work. So yet again you have proven my point.
Offline
rethinking the whole thread - what we need is a true 64bit Version
whats about to start wok-64 - just starting with kernel 4.0 RC5
Offline
@pankso:
llvm build still fails, cause you build with gcc4.9, but link against old libstdc++ version.
1.10 + rm -f $fs/usr/lib/libgcc_s.so*
1.11 + rm -f $fs/usr/lib/libstdc++.so*
1.12 + rm -f $fs/usr/lib/libgomp.so*
So need for new gcc-lib-base version.
Offline
@Trixar: I think there has been little argument here against updating the toolchain, at least not if i386 alone is dropped. But several people have suggested not to try to do it before releasing SliTaz 5, notably because that would delay it even more. Erjo told there remains only a handful of packages to fix. So what do you think?
Offline
And people will use something that's 3-4 years out of date? It's not about just releasing what we got, because what we got is outdated and semi-broken. What if SliTaz 6 suffers the same delays because we stubbornly didn't want to update and fix what is broken right now? Let's be realistic here: It's update or risk becoming irrelevant. It's update or risk never having a SliTaz 6. Am I the only one that sees that?
Bellard predicts a 10%-20% will break if we update. I predict it will be as low as 1%-2%. Whichever of us is right doesn't matter since 99% of the packages will compile with the exact same flags and process that's currently in the receipt anyway - all they need is library and source package updates. The remaining 1% will require some work to fix them. We could get ahead of this thing if tried. I'd do it myself if I had the resources, but I don't, so I need you guys to help get SliTaz's act together and create a better base for future releases like SliTaz 6.
Offline
> And people will use something that's 3-4 years out of date?
Yes. Currently some people even use ST 4! Because it's the latest stable. Not everybody needs or wants "bleeding edge" software. E.g. look at Debian, many system admins use the stable version because its behaviour is very well known (I know, Debian has many resources and they backport security fixes; I'm just suggesting an analogy).
Offline
Let me put it this way - Debian with it's long release cycle is ahead of us. We're that out of date. SliTaz 4 is even more so, because Debian Lenny was still new when it came out.
There's a difference between bleeding edge and having packages so old that they still have bugs in them that have been fixed for years. That's what you want us to release to the public as stable.
Offline
It is the reason why I did recommand to thing about a next SliTaz with self compiling ability! doing so, you would find all needed "pour ne pas faire du sur-place" yet in the experimental version... the other distro yet available started in French speak. Switzerland, NuTyx, does so and it is one of it's best figures against a lot of other distros in the world: it is "eating" each new SFS book as soon as possible after parution and, after that, you can delect the stuff of that new SFS book compiling yourself your Linux. The problem: NuTyx takes absolutely not in consideration minimalistic views and old hardware as well as NuTyx permanentelly changes and disturbs surprising so the users (not changes in the stuff but in the view of structure of a Linux distro). A mixture of both, constance in the "stable" based on a certain level of "cooking", fast evolution in the "cooking" beeing based on an open sources base would be more flexible... Note: after the first one, also the sources of the stable would be full operable in the same way making the stable more flexible for user willing to adapt themself the stable for the own uses.
Slitaz includes a ready to use figure not directly usuable in all distros, the localhost fully figured in /var/www
The self compiling system would be better based on it (download of a big actual packages iso of sources of packages as SliTaz did publish regulary until yet for binaries, unpacking in the localhost of the own PC and compiling it from this localisation).
Offline
> Let me put it this way - Debian with it's long release cycle is ahead of us.
I know, and I wrote it, if you read my post.
> That's what you want us to release to the public as stable.
No. As for me, I just asked for a RC3 (and erjo also suggested it). Much work has been done since RC2. Please, put a milestone now, for the sake of other people's work, before breaking it. (I'm not one of these people; I respect their work all the more so as I'm not.)
Offline
Hi,
Can some one have a look on this ?
http://people.slitaz.org/~erjo/5.0/
should prepare an announcement and a new theme
Offline
@erjo
Hi,
I have just testet, what You have posted. It works. You still called it RC2 in the isolinux.cfg file.
You should call in both isolinux.cfg
SliTaz GNU/Linux - 5.0-RC3 20150328
Offline
An rc3 candidate, at last! Thanks a lot, erjo!
I just quickly tried out your slitaz-5.0-rc3.iso and, alas, found that tazlito generated ISOs still bomb out with a kernel panic. As the ability to create customized ISOs is one of the most useful and prominent features in SliTaz this problem really should be sorted out once and for all in the upcoming rc3. Why can't we use the boot scripts that Aleksej, az_ua and Mojo have amended over 9 months ago ...
- Error loading "tazusb writefs gzip" generated initrd
- Kernel panic with rolling 20140611
... after which tazlito worked (almost) perfectly?
Offline
llev: SliTaz 3 was the last good version. The reason SliTaz 4 took so long and in itself wasn't perfect can be traced back to one person: Gokhlayeh. He wasn't a bad developer, but he did write his own build system that not only broke rebuilt packages, but caused a bunch of bad builds to pop up. This is why Bellard believes we'll have a 30% breakage because that's exactly what happened with Gokhlayeh's mess. Dare I do the math? We've been sitting with his mess nearly 5 years now. I for one feel we should start over with a clean and updated slate. Btw llev - stop arguing semantics while ignoring my good points.
I'm honestly done arguing with people too stubborn or jaded to listen to reason. Let the chips fall where they may. We'll probably have to pick up the pieces like the current devs of TinyCore did with DSL.
Offline
@erjo,
Hi,
slitaz-5.0-rc3.iso
boot=OK
tried to create a LiveCD (Applications > System Tools > Create a LiveCD
[*]Based on core:
[c]wget: server returned error: HTTP/1.1 404 not found
Missing package: tazpanel-1.8.4[/c]
[*]with [Write ISO]
[c].../
find: home/tux/.gvfs: Permission denied
Creating rootfs.gz with lzma compression... [/c]
and kernel panic at boot
[*]no way to simply specify a path to an ISO and burn the CD? It seems to me it was possible on previous releases.
tried to create a LiveUSB
[*]if no stick inserted, TazUSB Box indicates [c]USB Media: none[/c]
if a stick is inserted, TazUSB Box lists all the devices HD and USB; no way to display only USB devices?
[*]no notification if there is already something on the stick and don't write anything on it
[*]tazusb does not propose to format the stick before to create the Live; same with gen-liveusb
I'll try to continue to test tomorrow.
Offline
I've done 2 full install through TazPanel; on both, the kernel hasn't been copied in /boot.
Offline
@Ceel. Thank you for testing.
Stop testing they are too buggy.
I removed them.
Offline
> Stop testing they are too buggy.
Thanks for the effort erjo.
The donkey that I am wonders how much time it would take to come up with a less buggy RC3 based on a new toolchain. 
Offline
Yes, thank you erjo to have try, next attempt will be good :-)
The problem with kernel is not specific to your rc3; same with the ISO 20150327 and may be with previous. It's a bug in the installer.
I installed from a terminal using tazinst; here is the error message when copying the kernel:
[c]50 Installing the kernel...
cp: can't create '/mnt/target/boot/vmlinuz-3.2.53-slitaz/media/source/boot/bzImage': No such file or directory
install_kernel: vmlinuz-3.2.53-slitaz[/c]
The donkey that I am wonders how much time it would take to come up with a less buggy RC3 based on a new toolchain.
I felt a little lonely on this case. Excepted 2 or 3 guys, where are all these people who have been calling for several months a new stable release? I didn't see their feedback...
Thanks again erjo.
Offline
I have an idea. It's based on the fact that our packages are out of date because we don't have the developers to deal with it.
So what if I could eliminate the need and get us several million packagers that maintain 100 thousand up to date packages? It will also instantly give us 64bit and ARM capabilities too.
Would that be worth it?
Offline
>Would that be worth it?
Depends on what do you mean (Puppy-like?).
Offline
Simply that if our base is broken and some of us are too meek to fix it, that we could just use another distro as base and turn it into a SliTaz. We'll gain it's up to date packages, stability and features near instantly.
I'll admit that I get a bit destructively creative when openly ignored. Still this is just a short term solution. Now we can fearlessly rework our packages and still release a working SliTaz using (for now) another distro's packages. I expect a very bad backlash from this - so bring it on since I've already started this process myself.
Offline
Hi Trixar,
Are you talking about using binary packages? Because few distros compile with -Os I guess, so the choice may be very limited. But I don't know many distributions.
Offline
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.58 MiB (Peak: 1.77 MiB) ]