Angstrom Next

[sebt3]

The angstrom devel seems to be readying the next version of their distro.

This bump (for now) :
- glibc 2.9 to eglibc 2.11
- libstdc++ 4.3 to 4.4
- xorg server 1.7.1 to 1.8.1
- kernel 2.6.27 to 2.6.32 (beagleboard)

This would bring us way closer to what debian/ubuntu provide as base system. So there is hope that this fix the chromium problems.
But this also mean a lot's of work and (I'm no expert) might break compatibility with some binary (pnd).


What do you think ?

 

[EvilDragon]

Well, most of the work would probably be the kernel change - if absolutely necessary.
Most of the packet should work okay, we just need to put the Pandora specific patches back in

 

[Alibobar]

Still quite a lag on the kernel.

Common people. The stable is 2.6.35.4 atm

 

[Magic Sam]

Hi,

@ Alibobar: it's not a race where you always have to use the latest kernel you know

I'm still using kernel 2.6.26-2-amd64 (in Debian "Lenny" 5.0.6) and it runs fine on my quite high end laptop

I'm sure 2.6.32 will be sufficient for the Pandora and its hardware.

Bye, Magic Sam

 

[CPUnltd]

if PNDs are anything like RPMs PKGBUILDs, DEBs or anything else of the sort (linux prepackaged software for a particular distro), I'd expect the majority of work for PNDs that fail with the new kernel or other software would be able to recover from a (possibly) simple recompilation/rebuilding of the PND... worse case scenario I can think of is possible code changes to suit new software bases, but that is the nature of the concept behind "compatibility"... I'd hope/expect any PND dev to understand that PNDs would essentially "suffer" the same upgrade path concepts that RPMs, DEBs and such deal with... but I could be assuming more than I should and a few devs out there coded their PNDs with the expectation that core software like kernels and glib would not change for a long time. I'd hope not, but you never know. And it would be rude of me to not at least acknowledge such.

 

[paulguy]

I think most PNDs would break on a new [e]glibc or SDL and maybe GTK+, but I don't think those change much. Mostly depends on how strict the versions things require, I guess.

Kernel, believe it or not, probably won't break too much stuff as far as PNDs go. Most things don't depend on a different kernel or even need a recompile after a kernel update.

Also, PNDs often have a LOT of stuff statically linked or included with them. That helps quite a bit.

 

[Letalis Sonus]

Newer stuff is less likely an issue, especially those core components like the glibc and GTK+ are fully backwards compatible. Many companies and groups providing closed source software/precompiled binaries for Linux are simply using ancient versions of glibc to make them run on like any system out there.
To break something with a new GTK+ version, the program really needs to rely on stuff that has been marked as deprecated a long time ago. Unless OPT is switching to GTK+ 3 and omits the older GTK+ 2 libs I really don't see a problem there.
Usually it's much messier the other way round: Getting recent programs to run with older versions of GTK+, glibc etc.

 

[fusion_power]

Still quite a lag on the kernel.

Common people. The stable is 2.6.35.4 atm

I hope we will see the new Kernel for the current Pandora Angstrom at least this year. So much (interesting) stuff depends onto the new Kernel, it should be T-O-P Priority over everything else onto the Pandora. Yes, even Emulators.

 

[Alibobar]

The stable is 2.6.35.4 atm

2.6.35.5 even!

 

[Pleng]

Aren't odd denominations unstable releases?

 

[sebt3]

Aren't odd denominations unstable releases?

since 2.6, there is no notion of stable/unstable just release.

 

[Letalis Sonus]

Aren't odd denominations unstable releases?

The last (4th) number is just the revision, meaning they just added security fixes n' stuff like that.
That version numbering system was only used until 2004 and only affected the 2nd version number.
http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering