gentoo

Gentoo/MIPS Status Update

Well, been some time now since I announced the start of some µClibc stages.  So far, not much has happened there other than the fact that I’ve successfully hard-locked the Fulong 2E system that I tried compiling on.  This is despite compiling with binutils-2.21 and using -Wa,-mfix-loongson2f-nop… which is usually enough to prevent lockups.  Clearly there’s further erratum that I’m hitting, I might try later on the Qube and see where that gets us, agonisingly slow might be better than the current pace.

Generic N32 MIPS-III little endian continues to remain unavailable due to an issue compiling Python 2.7, and unfortunately my N32 chroot on the Yeeloong broke when I upgraded glibc (the primary reason why I began doing a generic MIPS3 build on the Qube using Matt’s MIPS4 build).  I will get back onto this eventually.

On other news since the purchase of the MacBook I’ve been able to leave my Yeeloong sit at home running continuously to update the entire system.  Qt 4.7.2 gave me some grief — it seems at least on mipsel, qmake segfaults during the initial build of qt-core …

mipsel-unknown-linux-gnu-g++ -o "/tmp/portage/x11-libs/qt-core-4.7.2-r1
/work/qt-everywhere-opensource-src-4.7.2/bin/qmake" project.o property.
o main.o makefile.o unixmake2.o unixmake.o mingw_make.o option.o winmak
efile.o projectgenerator.o meta.o makefiledeps.o metamakefile.o xmloutp
ut.o pbuilder_pbx.o borland_bmake.o msvc_vcproj.o msvc_vcxproj.o msvc_n
make.o msvc_objectmodel.o msbuild_objectmodel.o symmake.o initprojectde
ploy_symbian.o symmake_abld.o symmake_sbsv2.o symbiancommon.o registry.
o epocroot.o qtextcodec.o qutfcodec.o qstring.o qtextstream.o qiodevice
.o qmalloc.o qglobal.o qbytearray.o qbytearraymatcher.o qdatastream.o q
buffer.o qlist.o qfile.o qfsfileengine_unix.o qfsfileengine_iterator_un
ix.o qfsfileengine.o qfsfileengine_iterator.o qregexp.o qvector.o qbita
rray.o qdir.o qdiriterator.o quuid.o qhash.o qfileinfo.o qdatetime.o qs
tringlist.o qabstractfileengine.o qtemporaryfile.o qmap.o qmetatype.o q
settings.o qlibraryinfo.o qvariant.o qvsnprintf.o qlocale.o qlinkedlist
.o qurl.o qnumeric.o qcryptographichash.o qxmlstream.o qxmlutils.o  -Wl
,-O1 -Wl,--as-needed                           
floatmath auto-detection... ()                                         
/tmp/portage/x11-libs/qt-core-4.7.2-r1/work/qt-everywhere-opensource-sr
c-4.7.2/config.tests/unix/compile.test: line 71: 25542 Segmentation fau
lt      "$OUTDIR/bin/qmake" -nocache -spec "$QMKSPEC" "CONFIG+=$QMAKE_C
ONFIG" "CONFIG-=debug_and_release" "LIBS*=$LFLAGS" "LIBS+=$MAC_ARCH_LFL
AGS" "INCLUDEPATH*=$INCLUDEPATH" "QMAKE_CXXFLAGS*=$CXXFLAGS" "QMAKE_CXX
FLAGS+=$MAC_ARCH_CXXFLAGS" "QT_BUILD_TREE=$OUTDIR" "$SRCDIR/$TEST/$EXE.
pro" -o "$OUTDIR/$TEST/Makefile"                                       
gmake: *** No targets.  Stop.                                          
floatmath disabled.                                                    
... etc for numerous other modules.

qt-4.6.3 builds without issues, but this is not sufficient for KDE 4.6.  I’m still investigating.  hyperestraier also fails to build, but only if you have USE=debug set, disable that USE flag and it builds without issues.

Fingers crossed, I can get Qt 4.7 and KDE 4.6 to build, and that there aren’t any issues.  Previously libkjs used to be quite unstable which is one of the main reasons I have not keyworded any release of KDE 4 for MIPS.  Yes, you could dodge around it and have a usable desktop, but I didn’t consider it working well enough for keywording.

Mozilla stuff will need some loving too.  I hope to upgrade to Firefox 4.0 on MIPS, see how that goes.  One of these days I’ll get onto tackling Thunderbird.  Sadly my life away from Gentoo intervenes and thus my plans frequently get put on the backburner as work demands my attention elsewhere.

Bootstrapping Gentoo/MacOS X (Prefix) – automatically

Well, I’ve done some tinkering with Gentoo/Prefix on MacOS X.  Not bad so far, although there’s a lot of packages not keyworded… (a bit like MIPS) and some packages I miss from regular Gentoo (e.g. crossdev).  However, we can work on sorting this out over time.

For those of you who aren’t particularly fond of going on a copy/paste fest from the documentation, I decided rather than sit there all night and manually do it, I’d code up a script to do it for me.  Behold: Gentoo MacOS X bootstrap script.

Usage:

$ export EPREFIX="${HOME}/.gentoo/amd64"
$ export CHOST="x86_64-apple-darwin10"
$ mkdir -pv "${EPREFIX}"
$ sh do-bootstrap.sh

uclibc-0.9.31 + Loongson 2E + bzip2 + -Os CFLAGS = crash

Well, one thing I’ll need to investigate… I’ve been battling a slightly broken bzip2 which when compressing some files, would cause the whole machine to lock up.  Environment is µClibc-0.9.31 based, using gcc-4.5.2.

Everything compiled with the CFLAGS: “-Os -pipe -mips1 -Wa,-mfix-loongson2f-nop”.  The latter flag is really for Loongson 2F but I find it helpful on 2E as well.  Things seemed to go well, except that I had no end of problems with the machine locking up when running bzip2 on some files.  I found it reproduceable while building autoconf within Catalyst stage 1.

It would appear it’s a compiler issue, as when I rebuilt bzip2 using the CFLAGS: “-O2 -march=loongson2e -Wa,-mfix-loongson2f-nop”, it worked fine.  I will have to investigate this further.  I don’t think it’s a MIPS-I vs Loongson 2E issue, my hypothesis is that -Os generates some instructions that Loongson 2E doesn’t like, as I normally don’t have any problems running MIPS I binaries… the thing that’s significantly different is -Os vs -O2.

Gentoo/MIPS µClibc stages

Well, it seems I might have µClibc stages going again, at least for little endian initially, then I might fire up one of the SGI boxes and see about a big-endian version.  For a long while, Gentoo/MIPS support for this lightweight C library was all but missing ever since an ABI change broke the µClibc port back around 2006.

I’ve tried on several occasions to build a new environment, and often I was met with technical difficulties which prevented me from producing a working environment.  Recently, I downloaded Rob Landley’s Aboriginal Linux distribution, both big and little endian variants, and took it for a spin.  Having done that, I’m pleased to report that I now have a µClibc chroot that’s merrily compiling various components of the Gentoo system, and will soon be sufficient to make a seed stage for bootstrapping the port once again.

This should mean new netboot images in the medium term for all little-endian ports (and proper ones too, not glibc-based hacks) and new images for SGI Indy (R4000) and O2.  In theory, support for Octane and Indigo2 R10000 is possible, however the systems I have are no longer functional, only my Indy and O2 still work, thus it’s impossible for me to test media for other systems.  Fingers crossed this initial build will go to plan, and we’ll have shiny new stages shortly.

YubiKey ebuilds and patches for Gentoo

Hi all,

As promised I’ve put up some of the ebuilds needed to use the YubiKey in Gentoo.   This includes a PAM module for stand-alone authentication with the YubiKey, which I have patched to support concatenated two-factor authentication.  These are in a new overlay:

  • git://git.longlandclan.yi.org/overlays/yubikey.git
  • http://git.longlandclan.yi.org/git/overlays/yubikey.git

Stand-alone two factor authentication: Password + YubiKey with YubiPAM

The procedure for setting this up is pretty simple.  First, grab the overlay:

stuartl@beast /home/portage/overlays $ git clone git://git.longlandclan.yi.org/overlays/yubikey.git
Cloning into yubikey...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 16 (delta 2), reused 16 (delta 2)
Receiving objects: 100% (16/16), 4.15 KiB, done.
Resolving deltas: 100% (2/2), done.

Now add it to your make.conf as per usual procedure, then unmask and install YubiPAM and ykpers ebuilds.  At last check, you need the live git ebuild for ykpers and libyubikey if you use the latest revision (2.2) keys like those handed out at linux.conf.au.  For the PAM module, I recommend using the non-live version, although a live ebuild is there for the adventurous (I had buffer overflow glitches).

# ( echo =sys-auth/yubipam-1.1_beta1
> echo =sys-auth/ykpers-99999999
> echo =sys-auth/libyubikey-99999999 ) >> /etc/portage/package.keywords
# emerge ykpers yubipam

This will install some tools to personalise the YubiKey and the PAM module.  At this step it’s now time to program the YubiKey.  This will break its ability to be used on the Yubico servers until you upload a copy of your new AES key to their site (see below).

Choose your public and private IDs, then program with the following command.  The fixed parameter should be 6-8 bytes long in hexadecimal.  If you intend to use this on Yubico servers later, it must be 6 bytes long, and must begin with ff.

# ykpersonalize -ofixed=$( modhex -h ffeeddccbbaa ) -ouid=112233445566
Firmware version 2.2.2 Touch level 1283 Program sequence 3
Passphrase to create AES key:
     Type in a long string of gobbledegook with lots of random letters,
     numbers and punctuation (not like this!) to keep people guessing.
     This will seed the AES keygen.
fixed: m:vvuuttrrnnll
uid: h:112233445566
key: h:afaaaa6021303d90740579cd7fc4e87f
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags:
extended_flags:

At the bottom it asks whether you wish to program the key.  It didn’t here because in fact I had snuck in a little parameter which I haven’t shown here.  You’ll want to make a note of the parameters it tells you though, especially the generated key.

Once complete, you then need to tell YubiPAM about it:

# ykpasswd -a -c -f ffeeddccbbaa -k afaaaa6021303d90740579cd7fc4e87f  -p 112233445566 \
        --user stuartl -o vvuuttrrnnlllrgjglvnicujhnhhecfeitjureidlcer
Adding Yubikey entry for stuartl
Using public UID: ff ee dd cc bb aa
Using private UID: 11 22 33 44 55 66
Passcode: Completed successfully.

The last bit should be generated from the YubiKey itself, just type the rest in then press the button and it should add you after asking for a passcode (which can be different to your regular system password).  The final step is to set it up with PAM.  This I’m not 100% sure of, but I achieved working authentication by configuring my /etc/pam.d/system-auth as follows:

vk4mslp2 yubikey # cat /etc/pam.d/system-auth
auth            required        pam_env.so
auth            sufficient      pam_yubikey.so concat_two_factor
auth            required        pam_unix.so try_first_pass likeauth nullok

It should be noted; test the configuration in a new console session, do not log out or else you may lock yourself out.  There is a ykvalidate tool for testing, but it doesn’t seem to work properly with two-factor authentication.

The concat_two_factor parameter to pam_yubikey relies on a patch present in the ebuild, which I have sent up-stream, and is a work-around for (some would say, broken) PAM clients that do not support multiple Password fields such as KDM.

To log-in, type in your username.  In the password field, enter the passcode followed by a space, then tap the YubiKey to enter the OTP.  It should log you in.

Uploading the key to Yubico

First, a warning

The whole point of one-time password generators such as this, is to prevent someone intercepting your password and logging in to your systems.  If a one-time-password is captured, it’s useless because in the ideal case, all systems know it has already been used.  I say in the ideal case.  In this scenario, if you use the key on a public server, it is possible for someone to capture that OTP, and re-play it to the stand-alone system using YubiPAM to gain access.  They of course can only do this once, but that may be enough for them to make themselves at home.

With some care, you can reduce the risk of this … for instance making a point of gratuitously logging in to each system using the key immediately after using it on any of the systems is one way to try and manually synchronise the OTPs.  I’m giving this problem some thought, for my needs it isn’t such a big deal as it’s mostly for fun anyway, but this is a factor that must be considered when using the YubiKey (or any OTP device) in this manner.

How to

Go to https://upload.yubico.com/.  Enter the data as follows.

  • Your email address (needs no explanation)
  • The YubiKey’s serial number: printed on the back, 6 digit decimal code
  • YubiKey Prefix: This is also called the “fixed UID” and appears as the first 12 characters of the OTP.  It should be in modhex format.  In the above example, the prefix would be vvuuttrrnnll.
  • Internal identity: This is also called the “private UID”.  It should be in hexadecimal format.  In the above example, the internal identity would be 112233445566
  • AES Key: Again in hexadecimal… the key used in this example was afaaaa6021303d90740579cd7fc4e87f
  • Finally, an OTP from the device. Don’t fill this in yet.

Below this form there is a Capcha field to stop spambots.  Fill in the challenge and click the “I’m a human” button, and copy the text into the other box as it asks.  Now go back to the other form, click on the OTP field and press the YubiKey button.  You should then be able to test it on their demo server and use the key simultaneously on the web and your local systems.

Gentoo and DHCPv6

Amongst playing with the YubiKey, I also had a look at DHCPv6.  As people well know, IPv4’s days are numbered, and given we’re all going to have to jump across to IPv6 fairly soon, I figured I had better get acquainted with the newer protocols that come with it.

I’ve had my network running dual-stack for some time now.  This has been achieved using stateless autoconfiguration and router advertisments, which work fairly well.  Today though I decided I’d give DHCPv6 a crack.  For this, you will need the latest ISC dhcp package, net-misc/dhcp-4.1.0, which is hard-masked.

I hope to get something more mature going, but here are some notes who may wish to try this at home.

Setting up DHCPv6

Start by installing the net-misc/dhcp-4.1.0, on both server and clients…you will need to unmask it first:

# echo =net-misc/dhcp-4.1.0 | tee -a /etc/portage/package.unmask >> /etc/portage/package.keywords
# emerge -a dhcp

The -4 and -6 flags

Now, that will install the DHCP server and client.  The catch that initially caught me is that ISC dhcpd cannot run on IPv6 and IPv4 simultaneously. Neither can the client, but we’ll get to that.  Both server and client are put into IPv4 mode by running with -4 in the options, or -6 for IPv6 mode.  Documentation says it defaults to IPv6 mode, but my experience has been the opposite (maybe a Gentoo patch does this).

Server set-up

Needless to say, if you’ve got your network running IPv4, at most you might have to edit /etc/conf.d/dhcpd to add -4 to the start-up options (DHCPD_OPTS to be exact).  Easy.  It’ll work as before. If you want IPv6, okay, make that -6 in DHCPD_OPTS, no sweat. But what if you want both? Ohh fun, we need a second dhcpd instance.

My solution; copy each /etc/init.d/dhcpd and /etc/conf.d/dhcpd to /etc/init.d/dhcpd-v6 and /etc/conf.d/dhcpd-v6 respectively.  Make the necessary changes to /etc/init.d/dhcpd-v6 and /etc/conf.d/dhcpd-v6.  So that the two don’t clash, I thought it wise to substitute DHCPD with DHCPDV6 using a text-editor (replace all).

You’ll also want to rename the leases file (dhcpd.leases, I chose dhcpd-v6.leases) and the PID file.  In addition the init script calls dhcpd to check the configuration in checkconfig(), so add -6 there too.  To save you going back and adding it in /etc/conf.d/dhcpd-v6, you can also add the -6 flag to the start-stop-daemon call in in start().  Do similar manipulations to /etc/conf.d/dhcpd-v6.

As for the server configuration file itself, I called my IPv6 config file /etc/dhcp/dhcpd-v6.conf to differentiate it from v4.  The two will need separate configuration files.  At the top of the v6 configuration file, you’ll want to point it to new PID and leases files:

pid-file-name "/var/run/dhcp/dhcpd-v6.pid";
lease-file-name "/var/lib/dhcp/dhcpd-v6.leases";

Adding that to the top of dhcpd-v6.conf will take care of this.  If you’ve done everything right, you should be able to start the DHCPv6 daemon, and add it to your runlevels as per normal.  DHCPv6 listens on port 547/UDP — look for it in netstat.

Client set-up

Client set-up isn’t too difficult, the fun bit is integrating dhclient into the init scripts.  OpenRC knows how to drive dhclient in v4-mode, but not v6.  It too, cannot run in both v4 and v6 mode simultaneously.  The solution: a new net module.  Copy /lib/rc/net/dhclient.sh to /lib/rc/net/dhclientv6.sh.

Rename all the functions changing dhclient to dhclientv6 (don’t use replace-all this time), and change the “provide” line in dhclientv6_depend to dhcpv6.  In dhcpclientv6_expose, do likewise, rename the variables dhclientv6 and dhcpv6.  Finally,  in each  call to the dhclient binary itself, add -6 to it to put it in IPv6 mode, and rename the PID file to add -v6 to the file name.

Save the new file.  Now in /etc/conf.d/net, use the following:

config_eth0=( "dhcp" "dhcpv6" )

Things that I have not yet figured out

Dynamic DNS

This is one of the reasons why I wanted DHCPv6 in the first place.  Remembering IPv4 addresses is bad enough.  IPv6 is a pain.  I have more success citing Pi than remembering the IPv6 address of all my computers.  The statically assigned ones aren’t too bad since the prefixes are all the same, it’s the autoconfigured ones that are a nuisance.

It should be doable, but I haven’t yet worked out how to make dhcp update the nameserver with AAAA records.  This is still in its infancy though.  Lots of rough edges.  I note dhclient doesn’t seem to be passing on the hostname of the computer, which could be part of the problem.

Address pools and class-based assignment

Address pools are handy things.  In ISC dhcpd, I can classify each of the computers I have by their MAC address and assign each class an address pool.  Or at least I could when it’s in IPv4 mode.

I have a nice set-up on IPv4 where if the DHCP server knows the MAC address, it’ll put that computer on the right subnet.  We have three IPv4 subnets here; one for my computers, one for my father’s and a “de-militarised zone” where any foreign computers get put (along with the web server, well actually it exists on all three).  Below is an example:

subnet 192.168.64.0 netmask 255.255.255.0 {
  pool {
    range dynamic-bootp 192.168.64.32 192.168.64.254;
    allow members of "stuartslan";
  }

  ddns-domainname "redhatters.yi.org.";
  ddns-rev-domainname "in-addr.arpa.";
  ddns-updates on;
  update-conflict-detection off;
  allow client-updates;

  /* ... */
}
/* ... */
subclass "stuartslan" 1:6c:f0:49:ef:84:7c; # beast eth0
subclass "stuartslan" 1:6c:f0:49:ef:84:7e; # beast eth1
subclass "stuartslan" 1:08:00:27:ab:7c:b9; # Win2K VirtualBox
subclass "stuartslan" 1:08:00:27:27:bf:55; # uClibc VirtualBox
subclass "stuartslan" 1:00:08:0d:5c:08:51; # Laptop "vk4mslp2" ethernet
subclass "stuartslan" 1:00:12:f0:bd:de:06; # Laptop "vk4mslp2" wireless
/* ... */

I haven’t figured out how to replicate this in DHCPv6.  The following does not work:

subnet6 2001:388:d000:1153::/64 {
  pool {
    allow members of "stuartslan";
    range6 2001:388:d000:1153::1000 2001:388:d000:1153::ffff:ffff;
  }

  ddns-domainname "redhatters.yi.org.";
  ddns-rev-domainname "ip6.arpa.";
  ddns-updates on;
  allow client-updates;
  /* ... */

I plan to keep researching these things, and I’ll see what I can do about getting the updates into Gentoo’s init scripts so that DHCPv6 is handled.  A lot of what I did today were quick hacks that will likely make people shudder, but it’s working for now, we’ll see how it goes.

LCA: Lemote boxes

Well one Lemote Fuloong 2F system has already been given away, and the new owner has been asked to try and find out about them.

Some of you may be aware of some Lemote related resources on my devspace.  I’ll try to get some Fuloong 2F stuff up there,  but I’m flying blind as I don’t have one of these systems.  The netboot and LiveUSB image you see online is for its older cousin based on the Loongson 2E CPU, and won’t work on the Yeeloong or the newer Fuloong, as the graphic chipset and northbridge differ substantially. The stage 3 tarballs (MIPS I or MIPS III little-endian) will work however.

I’ve got one of the Fuloong 2Es onto the case now however, we’ll see what we can get achieved over the next few days.

LCA2011 Day 1

Well, here I am.  Just registered and watching the stream flowing into the rego desk.  It’s not a queue, it’s the whole alphabet.  The only queue I’ve seen longer recently was the one to the checkout at the local shopping centre just before the flood peak.

Journey between The Gap and Kelvin Grove along Waterworks Road/Musgrave Road (to the Normanby Fiveways) took a bit over an hour, had a good conversation on the Mt. Cotton repeater, but evidently I’ve got a connection issue with the antenna.  That, and a bump just severed the connection between the battery and fuse holder, so I shall be riding home in silence tonight.  (Not the first time this has happened either.)

Not sure what to expect today, being my first time, guess I’ll find out.

On other news, Gentoo/MIPS I Big-endian stage 3 got uploaded last night.  Builds for other ISA levels continue.

Going with the flow

Well, that pretty much explains me the last few days.  Haven’t really done much planning, just been taking it one day at a time.  Ironically, it’s exactly what I recall seeing as the theme for linux.conf.au this year.  The very same year that the Brisbane and Bremer rivers decided to get out of bed and visit the neighbourhood.  Pity neither river thought to wipe their feet before flowing through peoples’ houses, leaving a trail of smelly mud behind.

Saturday and Sunday were spent over at Kenmore helping out my grandparents with the clean-up effort there.  As I was home alone, I relied on my one and only form of transport, the bicycle, riding (and walking) Gap Creek Road between The Gap and Brookfield.  Surprisingly, I can do that run in a bit over 1:20 or so, not bad for pedal power alone, and with a trailer loaded with gas bottle and camp stove to boot.

And of course today, seems I was a glutton for punishment, fronting up to Graceville State School and signing up to volunteer there along with my father.  So very little time spent in front of the computer this weekend.  Apart from the nasal assault the mud inflicted as we drove around Graceville area and the tiredness from all the running around, things aren’t too bad.  Our house here in The Gap suffered no ill effects from the floods.

Gentoo/MIPS builds have plodded along, I had to re-start the Qube2 building MIPS4 little-endian builds as it crashed for some unknown reason.  The O2 is busy building MIPS1 Stage 3 now as I type this.  The little-endian builds for MIPS1 and MIPS3 are already online in my devspace.  I’ll see about getting these moved to mirrors when the others are up too.  Cobalt users;  MIPS4 builds will be some time yet, if you’re desperate, the MIPS3 ones will work.

I’ve only uploaded the stage 3’s for now, since the stage 1’s gave me a slight hiccup with regards to python-wrapper, if you really want a stage 1 or 2 image, just throw the stage 3 at catalyst.

I did plan to try and at least get something going on the netbook as a bit of show-and-tell for linux.conf.au, which is rapidly approaching.  I probably won’t get time, but at least it’s working, so I’ll leave it for now.  I will definitely be there next week.  Those in the Gentoo community, we should definitely meet up at some point.  If you see someone riding in, looking like a postie with a bike downgrade, it’s probably me, particularly if the bike in question has an antenna or two mounted on it.

VK4MSL/BM on 2m

VK4MSL/BM on 2m: side view, will probably be seen at LCA2011

I’ve been ambushed by people lurking around it before.  I probably won’t have the coolie hat with me (too awkward to carry on a bicycle, and of course I can’t wear it with the helmet) so in terms of visual queues, that’ll have to do.  I’ll likely also be on the 2m band a lot whilst in-transit between The Gap and QUT where LCA2011 is to be held, so expect to hear me on 147.075MHz (VK4RAX) and 146.875MHz (VK4RBS) repeaters.  Sadly, no APRS yet, so you won’t be able to track me that way for now.

This week, a lot of nets and club activities also resume, including the Brisbane Amateur Radio Club, who meet at the Queensland Maritime Museum just across the water from LCA2011 at 7:30PM that Friday (the 21st)  for a business meeting.  Despite it being largely for business, we welcome anyone wishing to come across and say ‘ello.  Amateur Radio and the Open-Source community do have a lot in common.

In short, I’m cracking the whip on the O2, and hoping to have at the very least, MIPS1 big-endian builds up by the start of LCA2011, and I hope to meet a lot of you at this year’s LCA, which will be the first time I’ve attended one of these events.

Gentoo/MIPS O32: New builds

Recently, a new version of binutils was released.

I had reported earlier about some patches needed to work around errata bugs in the Loongson CPUs.  There were also some other big updates since.  GCC 4.5 and Perl 5.12 have both been unmasked, enough has changed to warrant a rebuild before things get too far out of date.

This release will come with binutils-2.21 which incorporates many fixes for linker issues on MIPS, as well as the Loongson errata.  I have successfully compiled KDE 4.5 using a CVS HEAD version of binutils snapshotted around the time that the 2.21 branch was created, and found that it has fixed quite a few issues.

If you haven’t upgraded just yet, hold on a few weeks and I’ll have new stages up for all to try out.  MIPS-I Little-Endian is building now as I type this, I’m in the process of building seed stages for big-endian builds.  MIPS-III and MIPS-IV little endian builds will begin very soon too (before noon AEST).

I expect I should have most of the little-endian builds up before new year, and the whole release out in early January 2011.