Nokia-N900:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
libgcc1 libnspr4 libnss3 libnss3-certs libqt4-core libqt4-dbus
libqt4-declarative libqt4-gui libqt4-maemo5 libqt4-multimedia
libqt4-network libqt4-opengl libqt4-phonon libqt4-script libqt4-sql
libqt4-sql-sqlite libqt4-svg libqt4-test libqt4-translations
libqt4-webkit libqt4-xml libqt4-xmlpatterns libstdc++6
microb-engine microb-engine-common mp-fremantle-community-pr
26 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.0MB of archives.
After this operation, 1163kB disk space will be freed.

More space freed and no problems so far

I tried to setup a thumb development environment a few weeks ago as described in http://talk.maemo.org/showpost.php?p...&postcount=164, but was not entirely successful.

First of all I did not exactly know where to set the sources.list (is it inside the scratchbox chroot?), and secondly, I could not set qemu-arm as CPU transparency method (only option was None).

Is the description not totally complete, or did I miss something?

The information in that post is a little outdated, for the last upgrade the toolchain is 4.7.2. Will upload the new toolchain along with up-to-date instructions as soon as I have some spare time.

in short,the used toolchain is http://www.snewbury.org.uk/maemo/lin...armv7a.tar.bz2

to set up qemu-arm as CPU transparency method you need to select qemu as devkit(along with debian-etch, git, svn,...)

you need to install updated libs from http://www.snewbury.org.uk/maemo/packages/scratchbox/ once your new target is up and running

sources.list should be modified from within the chroot environment

EDIT:
also you should add thumb repo in your SB chroot, so -devel packages used to be the ones from -thumb repo.

@freemangordon
After reading whole thread carefully (ufff!), I don't get one thing. Considering, that kp51r1 provides "kernel-feature-errata-workarounds" (not exact name, but You know what I mean), why You're still releasing new versions on kernel-cssu, until kp52 "prove to be stable"?

Asking just out of curiosity, + because it creates strange "race condition" where we swap between kernels (kp5* and kernel-cssu), depending on which one provides most up-to-date features (while both are the same in other aspects).

What is rationale for keeping both kernels afloat?

/Estel

@Estel: The repo should be self-containing, on the first place. Also I don't want additional noise because of extras-delel bugs, because of bugs in KP itself, etc. For example it took 2 revisions of KP51 and again we have a mess with the repo (-devel)

And the cherry - I am using kernel in thumb repo to test the future "community kernel", thus the name.

Thanks a lot for answering, it makes sense. BTW, are there any things, that Community Kernel will include, and Kernel-Power won't - thus, being rationale for testing things for community kernel in separate repo?

Also, considering this:
http://mg.pov.lt/maemo-irclog/%23mae...07-28T22:25:56

...chances are thin, until CSSU get forked (which, personally, I think will happen anyway, sooner or later).

/Estel

Why don't just use stable versions of kernel-power?

Why do we need separate Community Kernel? Kernel-Power acts as Community Kernel for years.

http://mg.pov.lt/maemo-irclog/latest...07-29T01:14:48

New update is out, bringing kernel-cssu3 (i.e. KP51r1). If you already have KP51r1 installed, no new kernel will be flashed.

Warning - kernel-cssu3 replaces the stock kernel, freeing some space in rootfs. But if something goes wrong, the reflash will be the only option AIUI.

In that case… why to name it kernel-cssu? Wouldn't it be better if it was an upgrade of kernel?