Tiny Core 5.0 Alpha 2 Testing

[Juanito]

Tiny Core 5.0 Alpha2 is available for public testing:

http://repo.tinycorelinux.net/5.x/x86/release_candidates/

Changelog for 5.0 alpha1:
* kernel update to 3.8.10 with (u)efi boot enabled
* option to use vmlinuz + rootfs.gz + modules.gz or vmlinuz64 + rootfs.gz + modules64.gz (where boot loader permits)
* aterm, freetype, imlib2, jpeg and libpng factored out of Xlibs/Xprogs
* glibc updated to 2.17 and recompiled against 3.8.x kernel headers
* gcc updated to 4.7.2, recompiled against 3.8.x kernel headers and cloog, gmp, mpc, mpfr and ppl
* e2fsprogs base libs/apps updated to 1.42.7
* util-linux base libs/apps updated to 2.22.2
* scm extensions have been dropped from this release

Changelog for 5.0 alpha2:
* util-linux updated to 2.23.1 due to blkid problems with qemu
* /usr/sbin/fstype modified for new blkid output (supress "/dev/sda" type output in /etc/fstab and mount gui)

Your continued feedback welcomed and appreciated

[gerald_clark]

kernel headers tcz would be nice.  I would like to add Ximeta ndas support.

[genec]

Consistent update to Syslinux (tcz, core.gz and ISOs) would be nice.

[coreplayer2]

Thankfully fluff_1_0_7 now compiles in TC-5.0 Alpha

I don't fully understand this but apparently there has been some change to DSO linking in a recent g++,  adding the linker flag -lstdc++ to the command line fixed fluff's make file.

more here
http://forum.tinycorelinux.net/index.php/topic,12928.msg90183.html#msg90183

[coreplayer2]

Opera9  from the tinycore-4.x repo works well in TinyCore-5.0, requiring no deps

Opening from the command line reveals only two ignored java modules, since they are java is no big issue, right??

[Juanito]

kernel headers tcz would be nice.  I would like to add Ximeta ndas support.

I guess you'd need to pm ^hats^ for linux-headers-KERNEL

In the meantime, see:

http://www.tinycorelinux.net/5.x/x86/release/src/kernel/

You can avoid a lengthy kernel preparation by:

Code: [Select]

$ make mrproper
$ cp config-3.8.10-tinycore .config
$ make oldconfig
$ make prepare
$ make modules_prepare
$ cp Module.symvers-3.8.10-tinycore Module.symvers
$ make SUBDIRS=scripts/mod

[Juanito]

Opera9  from the tinycore-4.x repo works well in TinyCore-5.0, requiring no deps

copied over

Thankfully fluff_1_0_7 now compiles in TC-5.0 Alpha

it would be good to pm the maintainer about that

[coreplayer2]

Thankfully fluff_1_0_7 now compiles in TC-5.0 Alpha

it would be good to pm the maintainer about that

Done, hopefully Michael will have a fluff in the repo soon

[coreplayer2]

To help out with extensions for tc-5.0 I contacted JasonW, maintainer of some apps I'm familiar with to assist in updating and am now in the process of submitting these ext.

bash 4.2   -submitted
hdparm  -submitted

next up are
wget - copied
Fluxbox -to do

[Juanito]

For the sake of clarity - there's no particular need to update the tc-4.x extensions for tc-5.x unless they will not run.

Of course if you'd like to update the extensions anyway (and the maintainer agrees) that's fine too.

The update to libpng has broken several tc-4.x extensions, but apart from that, the majority of the tc-4.x extensions should work fine - as testers conform the tc-4.x extensions work, they can be copied over to the tc-5.x repo.

[Juanito]

Consistent update to Syslinux (tcz, core.gz and ISOs) would be nice.

The tc-5.x iso are generated on the server and so use the server's syslinux.

One possible solution is that, as soon as we complete tc-5.x alpha testing, you could take over the syslinux extension maintenance and adjust it to be the same version as that of the server?

[coreplayer2]

Well I agree, sorry if I made it sound like I was updating everything in sight. have no fear, am not

I am not usually that lucky though, if I need an app then I can almost certainly predict an update will be required.   So far I have only found Opera v9 to function after the transfer.     My default "Shiretoko" Firefox based browser will not run on 5.0, like most apps this may be due to dependencies more than the apps themselves ?   Anyhow, I need certain apps to be functional when TC 5.0 rolls out so am taking proactive steps to test all apps I use, so far I haven't had much success.  hdparm, fluff, shiretoko, etc etc. 

Perhaps we should start a list of apps which need their maintainers attention?  perhaps the extension requests section is appropriate?   I was hoping to find maintainers all over this but haven't seen many reporting compatibility yet with their extensions, although I have noticed the app list silently growing in the 5.0 repo  which is great thanks

[bmarkus]

In general current 4.x extensions are expected to work. Issue is not the compatibility, but there are many unmaintained, old extensions which would need update independently of 5.x

[coreplayer2]

Thanks TC Staff for this great and most appreciated kernel update.   Just forgive me for being proactive, it's just that when you roll out the shiny finished product I need to be ready like yesterday..

[caminati]

Thanks for the update, I will give Alpha 2 a try.
Alpha 1 gave no particular problem with everyday usage.

Here I want to ask about the rationale of dropping scm support.
What is the reason? And is it a final decision?

My two cents on the issue: more than self-containedness, I regard the possibility of avoiding symlinking as the key feature of scm.
In case of software able to live outside the FHS and with many files, this means several megabytes spared when loading the extension.
A good example is LaTeX: in my recent submission of it to TC, I devised a mechanism to separate this huge piece of software into a "small" basic tcz which can compile basic TeX and LaTeX and initializes the environment to dispense with FHS, so that some additional scms can add the needed features.

The difference wrt to a standard texlive.tcz (using df -h ~) is some tens of megabytes.
Of course, I can keep this mechanism by mounting scms via a custom script, but the point I wanted to make is that scm have more than one reason to exist.