gentoo

Hi All…

Well, my stagebuilds are in full swing… at this rate, I hope to have stage1 up in a day or two, and I’ll be starting on stage2, etc very soon.
New Profiles:

The structure is much the same as the 2006.1 release, just replace “2006.1” with “2007.0” in your profile path. Portage will tell you what to do when we officially mark the profiles deprecated.  Or, you can switch ahead of time… e.g. on Cobalt:

# rm /etc/make.profile
# ln -sv /usr/portage/profiles/default-linux/mips/2007.0/cobalt/o32 /etc/make.profile

This will set your machine up with the new profile (using LinuxThreads… see below for NPTL).

MIPS1 Stages for Cobalt:

There has been some demand for such stage files for some time now, mainly for enthusiasts that wish to run Gentoo on mipsel machines that don’t implement the full MIPS4 ISA. In this release (after I get the MIPS4 stuff pushed out safely), I’ll build MIPS1 stages for those who wish to experiment. Please Note: We can’t help you with queries involving unsupported systems. For some userland-related issues, we may be able to provide some assistance, but anything involving hardware or kernel, you’re on your own.

The MIPS1 stages are primarily being used in a few unofficial ports of Gentoo to various architectures. I won’t say much more than that, as there are some legal issues which need to be addressed first… however, it is hoped these ports can go ahead. Naturally, I’ll let you know when this happens.

Heads Up – 2007.1 release:

In 2007.1, we plan to switch over to running NPTL across all MIPS platforms. At present, I’m doing some testing on mipsel using NPTL to confirm stability. Other MIPS developers have been running NPTL on SGI boxes for some months now with great success, so the code is considered reasonably stable now, even though it’s not keyworded as such. To use NPTL, switch to the nptl/ profile for your system, unmask glibc-2.4-r4, then upgrade glibc:

e.g. on Cobalt:

# rm /etc/make.profile
# ln -sv /usr/portage/profiles/default-linux/mips/2007.0/cobalt/o32/nptl /etc/make.profile
# echo '=sys-libs/glibc-2.4-r4 ~mips' >> /etc/portage/package.keywords
# emerge -a glibc

It would be greatly appreciated, if a few brave users could give this a try, and report back their findings.

Hi All…

Well, it’s that time of the year again… the lead up to release time for 2007.0. The official snapshot date is apparently next week sometime, which means I need to produce some pre-2007.0 stages in preparation.

Recently, I started the beginnings of an n32 port to Cobalt, with these stages being available from my devspace (contact me and I’ll provide the URL). In this release, I hope to provide stage1/2 tarballs (perhaps stage3 too) compiled for MIPS1, potentially allowing all standard (note; the PS2 and PSP are not standard) LE MIPS systems to run Gentoo. Users porting Gentoo to new platforms will still be largely on their own as far as support goes… but at least they’ll have a reasonable base system to work from.

Also on my TODO list, is to update the docs. Things aren’t too shabby, however there are some bootloader-related updates, now that arcboot has been punted from the tree, and arcload 0.5 is stable. CoLo will eventually need to be updated too… I’ve held off doing this, since I use my Qube2 as a file server, and thus value its availability. Also, since my PDA has decided to go on the blink, I’ve been without a convenient VT100 terminal to plug in… thus I’ll need to build a new null-modem cable to hook my laptop up.

Hopefully by next week, I’ll have some prerelease stages for 2007.0 (32-bit only for now)… and can start building the official stages once the snapshots are released by the Release Engineering team.

Hi All…

Well, after much waiting, I managed to get KDE 3.80.2 to build and run. What can I say? Right now it’s not much to look at (low-res screenshot 800×600 100kB, full-res screenshot 2MB 2048×1576), and there are loads of sharp edges, but this is to be expected for a pre-alpha release.

My impressions:

• The new build system — This is going to take a bit of getting used to, but cmake seems to do a nice job building KDE. And there’s progress displayed as each package is built — very handy with long-haul builds.
• Build Time was significantly lower in KDE 3.80.2, compared to KDE 3.5 releases
• Some of the core apps (Konqueror, Konsole…etc) seemed to work fine, although there were some instability issues. (not suprising) Konqueror also seemed to like picking up the resources from KDE 3.5.5, leading to some oddities in the interface.
• KDE Control Centre appeared to be broken, in that it would not display applets. kcmshell worked however.
• Some of the kicker Panel applets failed to work (e.g. the clock)
• The startkde script locks up half-way (loading the Window Manager). In the screenshots above, I had to run kdesktop, kicker and kwin manually from xterm.
• There appear to be DBUS communications issues that need to be resolved.

In short though… it’s early days, but it looks like we’ll be seeing a lot of behind-the-scenes action in this release. I didn’t see anything that resembled the ideas for Plasma, but perhaps that will come later. It’ll definately be worth having another look in a few months.

Now I know a number of you have been gagging for a guide on how to install KDE 3.80.2. Here’s a very rough guide.

Part 1: KDE Dependancies

For this release, you need a number of things:

• Qt 4.2.1 with D-BUS support
• D-BUS 0.95
• cmake 2.4.3

cmake is fairly trivial, just add the appropriate line into your /etc/portage/package.keywords to allow you to install version 2.4.3 (currently unstable on x86) and run emerge cmake.

For the others… you’ll need to unmask both ebuilds in package.mask, and will need to hack the Qt ebuild to enable D-BUS support. D-BUS 0.95 is masked at the moment, pending updated mono bindings. Qt 4.2 is masked, pending D-BUS 0.95. You’ll need to uninstall earlier versions of D-BUS in order to install the new release. Be prepared, this will break HAL, avahi, and anything else you have which uses D-BUS, so prepare to have a big rebuild task ahead.

To enable support for D-BUS in the Qt ebuild you’ll need to change the following:

1. Add dbus to the IUSE variable:

   IUSE="accessibility cups dbus debug doc examples firebird gif glib jpeg mng mysql nas nis odbc opengl pch png postgres sqlite xinerama zlib ${IUSE_INPUT_DEVICES}"

2. In DEPEND, put in the D-BUS dependancy (it’ll be commented down below):

   glib? ( dev-libs/glib )        input_devices_wacom? ( x11-drivers/linuxwacom )        dbus? ( >=sys-apps/dbus-0.93 )"

3. Update the qt_use function to pass -qdbus to the configure script (it’ll be commented out). Also, comment out the line below as shown here:

   use dbus        && myconf="${myconf} -qdbus" || myconf="${myconf} -no-qdbus" #      myconf="${myconf} -no-qdbus"

Once the updates are complete, run ebuild qt-4.2.1.ebuild digest. Then, install all of the above: emerge dbus qt.

Part 2: Installing KDE by hand

As mentioned earlier, this new release uses the cmake build system, which is a bit different to get used to. Some of the docs (namely the ones for kdebase) haven’t been written yet, but in short, the procedure is as follows:

1. Unpack the source tarball (tar -xjvf /path/to/sourcepkg-3.80.2.tar.bz2) into a temporary directory.
2. Create a build directory (mkdir sourcepkg-build), then change into it.
3. Run cmake -DCMAKE_INSTALL_PREFIX=/place/where/you/want/kde/3.80.2 -DCMAKE_BUILD_TYPE=debug /path/to/sourcepkg-3.80.2
4. Run make
5. (As root) Run make install

The tricky bit, is the arguments to cmake:

• -DCMAKE_INSTALL_PREFIX= specifies the directory in which you want KDE installed. I put my installation in /usr/kde/3.80.2 so that it was placed alongside my KDE 3.5 install (but not in a place where it would get clobbered). This location is entirely up to you.
• -DCMAKE_BUILD_TYPE= specifies the level of debugging to include. Valid values are debug (normal debugging), debugfull (full debugging) and profile (full debugging with test coverage).
• The last argument, points to the directory containing the sources.

The KDE components need to be installed in the following order:

1. kdelibs
2. kdepimlibs
3. kdebase
4. other packages

Those three above mentioned packages, will get you the desktop shown in the screenshots. I have not yet installed the remaining packages, but these three will get things up and running.

I don’t recommend people mess with this release, unless they know what they are doing… As I say though, I’ll be keeping a close eye on this release, as it looks like there’s going to be lots of goodies going in behind the scenes for us KDE users come release time. 🙂

I’ve been a KDE user since installing SuSE Linux 5.3, and seeing KDE 1.0 in all its glory. I later tried Gnome 1.0/Enlightenment, when Red Hat 6.0 was released, and numerous other desktops, but I always found myself moving back to KDE. Prior to this, I had been using window managers like AfterStep, WindowMaker, FVWM and Red Hat’s FVWM95 clone, AnotherLevel.
The other day, I was looking around on the KDE news site, and noticed KDE 3.80.2 had been released for testing. This is a prerelease version of the upcomming KDE 4 desktop, intended for developers to take the desktop for a spin, port their applications to it, etc… Given my interest in the desktop, I figured I’d download a copy and take it for a spin.

The new KDE uses a different build system to previous releases. KDE 3.5 and earlier used GNU autotools, but not anymore. You’ll need cmake 2.4.3 or above to compile KDE 4. You’ll also need Qt4.2, and dbus, which means fun-and-games with masking, modifying ebuilds to disable some tests, and in general, lots of nasty hacks. Unless you know what you’re doing, I wouldn’t recommend anyone try it.

Anyway… after much fiddling, I managed to get it building. Already, I notice something new. The new build scripts actually show the build progress, as KDE builds. This is handy if you’re running on slow machines, and the first time I’ve seen such a feature in use. Here (right) is what the start of the build looks like (low resolution, full resolution).
I shall upload some pics of the desktop the moment I get kdebase installed, but so far, this is prooving very different to previous releases of KDE.

Hi all…

Yep, the first 64-bit userland stageballs for Cobalt are well underway. A stage 1 tarball is being uploaded right as I type this, and Catalyst is just starting up the bootstrap script now to get the stage 2.

I also began a build for µClibc, but I’ve hit technical issues with Portage there, which I need to work through before I can make stages with it.

I won’t mention the link where to download them at this early stage, because these are über-experimental. They’re totally inappropriate to be used as a root userland, even on a crash-and-burn box at this stage, and will likely be that way until at least 2007.0 or even 2007.1. For those who know what they’re doing, I’m happy to provide the links to these experimental builds, ping me on IRC/IM, or shoot me an email.

On other news… the stable 32-bit glibc builds for 2006.1 will soon be moving to a mirror near you.
As always, I’ll keep you posted on the progress. 🙂

Hi All…

Whilst forging ahead into new territory for the Gentoo/MIPS project on the n32 front, I also figured now would be a good time to update the µClibc stages for mipsel.

I’ve completed a cross-compile from x86 of an entire mipsel environment, and I’m now just about to set this up to use as a seed stage in Catalyst.  Once this is done and I’ve bootstrapped a system with it, I should be set to build a full mipsel environment.  This will be compiled for MIPS-1 class CPUs, and thus should be compatable with embedded devices such as wireless routers.  Note: This does not mean we will officially start supporting wireless routers.  They are still officially unsupported, and users are very much on their own when troubleshooting problems on these devices.

I’ll keep you all posted on the progress. 🙂

Hi All…

A few days ago I mentioned I’d be uploading the new stage 3 tarball for Gentoo/MIPS… I’ve now done this, and for now, you can find it in my devspace. Cobalt users… please give this stageball a try and report back… I’d like to get things checked out early before I get it pushed out to the mirrors.

Also needing attention, is the handbook. My draft version has been updated with the new profiles I mentioned in my last post, as well as other corrections. Any typos, mistakes, ommissions… please let me know. 🙂

Regards,
Stuart Longland

I’ve finally completed the Gentoo 2006.1 stage 3 tarball… I’ll hopefully be uploading this on Tuesday when I’m next at uni.

Over the next week, I’ll be updating the handbook, and putting together some new netboot images. Things to look out for — the profiles have moved somewhat since the last release.

The profiles are now arranged as follows (Comments mine):

stuartl@beast /usr/portage/profiles/default-linux/mips $ find . -type f -name make.defaults -exec dirname {} \;

Outdated 2006.0 profiles
./cobalt/2006.0
./mips64/ip28/2006.0
./mips64/multilib/2005.1
./mips64/multilib
./mips64/multilib/2006.0
./mips64/n32/2006.0
./mips64/2006.0
./2006.0

New profiles
./2006.1/cobalt/o32/nptl Cobalt with NPTL (not ready for production use)
./2006.1/cobalt/o32 Cobalt (using linuxthreads, recommended for Cobalt users)

Generic Big Endian profiles (including SGI Indy, Indigo2 R4x00, O2)
./2006.1/generic-be/n32/nptl
./2006.1/generic-be/n32
./2006.1/generic-be/n64/nptl
./2006.1/generic-be/n64
./2006.1/generic-be/o32/nptl
./2006.1/generic-be/o32

Profile for SGI Origin 200/2000
./2006.1/ip27/n32/nptl
./2006.1/ip27/n32
./2006.1/ip27/o32/nptl
./2006.1/ip27/o32

Profile for SGI Indigo2 Impact R10000
./2006.1/ip28/n32/nptl
./2006.1/ip28/n32
./2006.1/ip28/o32/nptl
./2006.1/ip28/o32

Profiles for SGI Octane/Octane2
./2006.1/ip30/n32/nptl
./2006.1/ip30/n32
./2006.1/ip30/o32/nptl
./2006.1/ip30/o32

You’ll also notice… we’re working on NPTL support on MIPS. The new glibc-2.4 no-longer includes support for linuxthreads, and thus all architectures are migrating across. NPTL support requires gcc-4.1, kernel 2.6.17, and use of the NPTL profiles. This is a work in progress and is not recommended unless you know what you’re doing. It is recommended people stick to using linuxthreads until things are stable using NPTL.

As mentioned earlier… this will be going into the handbook. If people have any questions… feel free to drop in, we lurk in #gentoo-mips on irc.freenode.net.