Adium 1.2.3 is now available. This is a quick bugfix release which exists primarily to address an issue in Adium 1.2.2 which prevented Yahoo! Messenger accounts with non-@yahoo.com usernames from connecting. It also fixes failures with certain additional message styles from AdiumXtras and corrects a few other minor issues with Adium 1.2.x. The version history has the details. Quack on!

A number of you have reported being unable to sign into Yahoo! using Adium 1.2.2. We’ve discovered the problem; this post is to tell you what we did wrong and what we’re doing about it.

When you enter a Yahoo! email address (such as jdoe@yahoo.com) into the username field in Adium 1.2 and later, Adium strips off the @yahoo.com part before trying to sign in with it. This is because Yahoo! expects only the jdoe part (the username); signing in with the whole email address will result in an unknown-username error.

Back on the 11th of February, Evan committed this change:

Yahoo accounts shouldn’t include the @domain.suffix regardless of what it is (e.g. @yahoo.com, @yahoo.it). Generalize our removal to account for this.

Before that change, we looked for “@yahoo.com” specifically, and removed it if present. This didn’t work for other Yahoo! suffixes, such as “@yahoo.it”. Thus, Evan intended to make Adium delete all Yahoo! suffixes, not just the US one.

The code that Evan committed removes any email-address suffix—in other words, if there’s an @, Adium will remove that and anything after it before trying to log in. This was a good plan, except for those who use Yahoo! AT&T.

SBC was a US telephone company, which became AT&T back in 2005. SBC offered, and AT&T still offers, an internet connection with Yahoo! services bundled, including Yahoo! Messenger. Instead of a plain old “jdoe” username, these customers’ Yahoo! IDs are their entire “jdoe@sbcglobal.net” address. For these users, stripping off the “@sbcglobal.net” suffix makes sign-in not work.

So, this is a regression. I’ve already committed a fix: we now only strip the suffix if the suffix starts with “@yahoo.”, so that “@yahoo.com”, “@yahoo.it”, etc. will be stripped but “@sbcglobal.net” won’t). That fix is present in what will be 1.2.3. While we’re at it, we know of a couple other regressions which we’ll also fix in 1.2.3.

Thanks for your patience, everyone.

News flash! Minor release of Adium with a major number of bug fixes! Grab it while supplies last!

Adium 1.2.2 is now available. It fixes a variety of bugs and crashes and is a recommended download for all Mac OS X 10.4 or later folk. Check the version history for the details.

Don’t forget to read Contributing to Adium to learn how you can submit patches and code, help hunt down bugs, and donate to support the project!

We greatly appreciate the donated resources of our excellent site and code host NetworkRedux and our download host CacheFly. 🙂

I did in fact solve the problems we were having with Adium‘s install of buildbot. It turns out that because of some security features of Mac OS X, I needed to start the buildbot process from an actual Terminal window on that machine, not from ssh. You can read about all this (and much, much more!) in this technote.

A big thank you to everyone who helped out, especially Keith, Rob and Ben.

The following is cross posted from my personal blog, in case you’re subscribed to both and think you’re seeing duplicates, you’re not.

So a while ago I set up buildbot for Adium. Briefly, buildbot provides continuous integration (i.e., building the source tree after every checkin) and runs our unit tests automatically. Cool stuff, and hats off to the buildbot team. Things seemed to be running fine for a while, no problems. However, recently we’ve started to get some odd errors on the machine we use for running builds, a Mac Mini named smew¹.

Subversion began to fail looking up DNS requests. I could only reproduce the problem when buildbot was running svn. If I logged in, I could run the exact same commands myself. And even more curiously, telling buildbot to run nslookup svn.adiumx.com worked completely fine.

I “solved” this by having the buildbot master (on a Linux machine) doing the lookup and then telling the client to checkout svn://<ip here>. If the IP of the subversion server changes, we just need to do a clean build and it’ll pick up the change. It’s not a great solution, but definitely workable.

This worked either briefly or perhaps not at all, I don’t recall, because our automated tests began failing like so:

/Developer/Tools/RunUnitTests:298: note: Started tests for
architectures 'ppc i386'

/Developer/Tools/RunUnitTests:301: note: Running tests for
architecture 'ppc'

Wed Feb 13 02:07:40 smew.adiumx.com otest[41048] <Error>:
kCGErrorRangeCheck : 
On-demand launch of the Window Server is allowed for root user only.

Wed Feb 13 02:07:40 smew.adiumx.com otest[41048]
<Error>: kCGErrorRangeCheck :
 Set a breakpoint at CGErrorBreakpoint() to catch errors
as they are returned

2008-02-13 02:07 otest[41048] (CarbonCore.framework)
FSEventStreamStart: ERROR:
 FSEvents_connect() => (ipc/send) invalid destination port (268435459)
FAILED TO GET ASN FROM CORESERVICES so aborting.

/Developer/Tools/RunUnitTests: line 301: 41048 Abort trap              
arch -
arch "${TEST_ARCH}" "${TEST_RIG}" "${TEST_BUNDLE_PATH}"

/Developer/Tools/RunUnitTests:314: error: 
Test rig '/Developer/Tools/otest' exited abnormally
with code 134 (it may have crashed).

** BUILD FAILED **

This is particularly strange because again, I can run these tests manually and get proper results. Same user buildbot is running in (and that user is logged in to the machine and has a window server connection), same checkout, same everything, near as I can tell.

This may or may not be superstition and it is probably just a coincidence, but sometimes these tests do run, and it seems that when I am logged in to the machine via ssh things work OK. But after I log out, things go screwy again. It’s something screwy with that particular machine — I had the buildbot slave running on a Mac mini while I was at Mozilla and it worked just fine.

I’ve run a permissions repair. It fixed some things. Still no dice. Buildbot is using the python installed by Leopard. The machine is fully updated, none of that fixed the problems (not even the Leopard graphics update). This machine is located at a colo somewhere inaccessible (Mars?), so while doing an archive and install would normally be my next step, I don’t have easy access to the machine.

I’ve done everything I can think of that I can do easily. Help me blogosphere, you’re my only hope.