Tiny Core v4.0 Alpha 2 Testing

[roberts]

Tiny Core 4.0 Alpha2 is available for public testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/alpha/

Change log:

alpha1:
* Updated kernel to 3.0.3
* Updated udev to 173
* Updated glibc to eglibc-2.13
* Updated e2fsprogs base libs to 1.41.14
* Updated gcc base libs to 4.6.1
* Updated util-linux base libs to 2.19.1
* Updated all the custom core utilities to use the new repository area:
   http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/

alpha2
* New loadcpufreq to handle module loading.
* Updated eglibc for 486/586 support.
* Updated busybox 1.19 with latest patches and fix for chpasswd segfault.
* Updated ondemand for console based extensions via Freedesktop Exec=cliorx prgname
* Adjusted .xsession to handle X startup failure.
* Adjusted .setbackground colors for wallpaper handling.

[maro]

Good news, the two items I mentioned about 4.0a1 are resolved.

So, as was the case in the later stages of the TC 2.x phase a rebuild of the 'libc' resolved the 'Xvesa' failure when run in a QEMU VM with KQEMU. This seems to be somewhat connected with what is labeled as "486/586 support".

I wonder what it was exactly that was changed for the 'eglibc' rebuild. To know this might help me in the future if I stumble somewhere else over a similar issue again.

[Juanito]

I wonder what it was exactly that was changed for the 'eglibc' rebuild. To know this might help me in the future if I stumble somewhere else over a similar issue again.

The issue is that the eglibc documention seems to be incorrect as regards compiling for i486/i586 compatibility, "--host=i486-pc-linux-gnu --target=i486-pc-linux-gnu" was required, wheras the documentation stated only "--host=i486-pc-linux-gnu" was needed.

[gerald_clark]

TC now works on Vortex86 SOC.
Also tested with MC, Xorg-7.4 and Xorg-7.5, and flwm_topside.

[gerald_clark]

My mistake, nbd.ko.gz is present.

Busybox was apparently compiled without nbd-client.

I compiled a standalone nbd-client for testing, and now have boot option "nbd=server:port tce=nbd0" working.
The  problem I am now having is that powerdown kills nbd-client before /dev/nbd0 is umounted.

[TheNewbie]

What kind of changes are to be expected in the TC 4.0 in terms of the actual 'core' (that is, those features, interfaces, and graphics, which are created for TCL)?

Also, is FLTK going to be updated to 1.3? I know that it is somewhat incompatible with earlier versions, but it's a much-needed update, I think, considering that 1.1.10 was released over a year and a half ago (somewhere on the order of 20-21 months); in comparison, 1.3 was released 3 months ago, relatively stable yet modern. If TC doesn't update FLTK now, then we'll probably have to wait yet another year for an update.

[Rich]

Hi TheNewbie
Just out of curiosity, are you looking for an update simply because something newer is available, or
because you are having a specific problem with the version currently in use?
 

[TheNewbie]

Hi TheNewbie
Just out of curiosity, are you looking for an update simply because something newer is available, or
because you are having a specific problem with the version currently in use?

I don't personally have a specific problem to deal with, I'm just wondering if the team/community considers it worth it, and asking whether or not such an update will be include it. It supposedly offers Unicode support, and I did have small issues with special characters when browsing the Web, but in general, an update would not bring many benefits.

For clarification, I am not looking for an update -- I asked whether it would be updated, and also stated some time frames for reference. I did use the words "much-needed," and those were specifically taking into account only those time frames. I don't think 1.3 would introduce major issues, but I understand if the team feels that it's not mature enough to warrant updating TC to use it.

Really though, I'm more worried about the TC-specific updates, as opposed to external lib availability and inclusion.

[Rich]

Hi TheNewbie

For clarification, I am not looking for an update -- I asked whether it would be updated,...

Poor choice of words on my part, I was just curious about your inquiry.

[roberts]

Re: fltk 1.3 See: http://forum.tinycorelinux.net/index.php/topic,10141.msg54736.html#msg54736

[hiro]

I don't see your problem. fltk 1.3 is already available in the repository.

It supposedly offers Unicode support, and I did have small issues with special characters when browsing the Web, but in general, an update would not bring many benefits.

What browser are you using that is built against fltk 1.1?

[hiro]

Has anybody tried building the core graphic apps statically against fltk 1.1?

[netnomad]

hi roberts,

just that you are informed:
with alpha2 the b44-modul of my broadcast-wired-eth0 isn't loaded.

that's my dmesg in alpha2:
b44: Unknown symbol ssb_device_is_enabled (err 0)
b44: Unknown symbol ssb_pcicore_dev_irqvecs_enable (err 0)
b44: Unknown symbol ssb_bus_may_powerdown (err 0)
b44: Unknown symbol ssb_pcihost_register (err 0)
b44: Unknown symbol ssb_device_disable (err 0)
b44: Unknown symbol ssb_device_enable (err 0)
b44: Unknown symbol ssb_driver_unregister (err 0)
b44: Unknown symbol __ssb_driver_register (err 0)
b44: Unknown symbol ssb_bus_powerup (err 0)
b44: Unknown symbol ssb_clockspeed (err 0)
b44: Unknown symbol ssb_dma_translation (err 0)

with 3.8.4 it's loaded properly and my dmesg looks like that:
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.

[Juanito]

I see two possibilities:

1. The ssb module needs to be loaded

or

2. The ssb module is loaded and it needs to be blacklisted (blacklist= boot code)

[curaga]

Right, ssb should be in the base and not in the wireless extension.