find first/ second/ -type d -not -empty -exec ~/fix-copied-dirtimes.sh \{\} \;

It is by far not optimized (being called this way will perform highly redundant queries on the file system) but it works very fast nevertheless and you usually don’t run it frequently, so that’s okay…

A little word of warning: Verify the correct behaviour on your own! That means: Please manually confirm that all calls performed by this script and method turn up with the correct result. This comes without any warranty and although touch shouldn’t do any more than changing timestamps you never know… So… do your checks please and try it on some unimportant test directories first.

#!/bin/bash
# sets one directory modification time according to its latest file modification time (searched recursively)

DIR=$1
LATESTDATE=`find "$DIR" -type f -printf '%TY%Tm%Td%TH%TM.%TS\n' | sort -n | tail -n1 | cut -c-15`

if [ $LATESTDATE ]
then
        touch -m -t "$LATESTDATE" "$DIR"
fi

1. Doubled dependencies
   We use Quartz Scheduler in our application while Geronimo itself also uses Quartz (however, in an older version). That resulted in a module conflict indicated by an IncompatibleClassChangeError since both libraries can not be loaded at the same time within the same classloader. The solution to this was rather simple: all that was necessary is adding <inverse-classloading /> to the deployment plan (which may better be placed in a separate directory so you can easily switch between multiple deployment targets). If our application was using Quartz 1.6 (the version Geronimo is using) I might have simply added a dependency to my deployment plan and could have shared the classes.
2. Missing XML implementation
   Our application also writes PDFs using the Apache XSL-FO processor. For a reason I still don’t understand, there appeared to be only stubs available but no implementations although it worked happily with apparently the same configuration on the same machine when run from mvn jetty:run instead of Geronimo. The message I got was something like “org.apache.xerces.jaxp.SAXParserFactoryImpl not found”. After a lot of search and failed tries I figured out that I simply had to add xerces/xercesImpl as a dependency. Another option may have been to dig deeper into property handling and figure out how to properly solve the problem by specifying an existing implementation as suggested on an older StackOverflow question. (however I’m unsure if that really was the problem as it appeared that the classes were missing but the class name was correct and it worked fine from command line so the classes – to my understanding – should have been available through the default class loader)
3. LinkageError
   The last problem I had to deal with took me much longer to figure out. Take a look at this part of a stack trace:

   
   Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "javax.imageio.metadata.IIOMetadata.getAsTree(Ljava/lang/String;)Lorg/w3c/dom/Node;" the class loader (instance of org/apache/geronimo/kernel/config/MultiParentClassLoader) of the current class, org/apache/xmlgraphics/image/loader/impl/imageio/ImageIOUtil, and the class loader (instance of <bootloader>) for resolved class, javax/imageio/metadata/IIOMetadata, have different Class objects for the type org/w3c/dom/Node used in the signature
   	at org.apache.xmlgraphics.image.loader.impl.imageio.ImageIOUtil.extractResolution(ImageIOUtil.java:54)
   	at org.apache.xmlgraphics.image.loader.impl.imageio.PreloaderImageIO.preloadImage(PreloaderImageIO.java:101)
   	at org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:175)
   	at org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128)
   	at org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:122)
   	at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81)
   	at org.apache.fop.fo.FObj.processNode(FObj.java:123)
   	at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:282)
   	at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171)
   	at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1020)
   	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
   	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
   	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
   	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
   	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   	at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:432)
   

   Let’s take a step back from that clutter of information, take a deep breath and examine the top-most sentence a bit closer:

   • we have some sort of class loader conflict
   • the method getAsTree in class javax.imageio.metadata.IIOMetadata refers to org.w3c.dom.Node
   • the class loader we are coming from is “MultiParentClassLoader”, provided by Geronimo
   • we come from org.apache.xmlgraphics.image.loader.impl.imageio.ImageIOUtil
   • the class loader being used by the method we try to call is called “bootloader”
   • the access to “bootloader” originates from javax.imageio.metadata.IIOMetadata
   • both class loaders link to incompatible and thus conflicting signatures of org.w3c.dom.Node, so we cannot continue

   Let’s interpret these facts: org.apache.xmlgraphics.….ImageIOUtil calls a method from javax.imageio.metadata.IIOMetadata. We have at least two class loaders that have different understandings of what org.w3c.dom.Node should look like and both classes we access are using a different one of these signatures. Apparently the javax packages are provided by the JDK and are being used by xmlgraphics, so our dependency of xmlgraphics appears to be incompatible with the JDK we are running. We are confident that both the JDK and xmlgraphics are up-to-date, so what next?

   I searched for over an hour and couldn’t find anything relevant except some voodoo stuff. At first I tried to hide classes by adding a filter in the deployment plan; then I tried to enforce one specific version by adding a direct dependency to org.w3c.dom. It was a bug report saying something like “strange, org.w3c.dom hasn’t been touched for years” plus another report saying “use xml-apis-1.3.04″ that got me on the right track: Today’s Java versions seem to ship with at least some org.w3c.dom classes. However, Maven pulled xml-apis as a dependency nevertheless which includes its own versions of org.w3c packages but doesn’t seem to be a problem unless deployed to the app server. Maybe that’s a side-effect of the inverse classloading we enabled to get Quartz running. The solution was to simply exclude that dependency in the pom file. If you are using NetBeans you can simply right-click xml-apis and select “Exclude Dependency” which will automatically add

   
               <exclusions>
                   <exclusion>
                       <artifactId>xml-apis</artifactId>
                       <groupId>xml-apis</groupId>
                   </exclusion>
               </exclusions>
   

   to all relevant dependency definitions (in my case xerces/xercesImpl and org.apache.xmlgraphics/fop).

It appears that this is an already reported issue with wine, as downloads made through calls to wininet.dll are supposed to be deleted by Windows sooner or later. As wine caches its downloads the same way but without ever removing old files, everything ever downloaded through wine’s wininet.dll currently gets cached indefinitely. To work around that problem, it’s currently necessary to clear that folder once in a while (or to automate that on reboots or similar). Simply deleting that directory should work just fine as it is supposed to be created automatically if needed.

It’s probably best to also search for other temp directories inside ~/.wine from time to time. Apart from cached downloads I could free another 6GiB of unnecessarily wasted space at the usual locations. It’s easy to forget about “C:” when running wine…

Sense’s initial release was very sluggish (see older reviews on YouTube) but has just become fixed when I ordered my phone. After that, there was one more update in November without information on what has been fixed with it. Since it required yet another wipe and was still Android 1.5 (Codename Cupcake) and everything worked fine for me so far, I decided not to install it.

It’s the end of May now, 6 months since that last update, 8 months since the UI fix and when I got my phone. Android 1.6 (Donut) was released the day after I bought my phone, providing new features such as VPN connections, text-to-speech support, a new market application and multiple screen resolutions. I would call the last feature the most important one since newer devices required it and soon applications started requiring that API, resulting in older Android versions not being able to run them (they are simply hidden from the market). In preparation of the Droid release in November Android 2.0 (Eclair) was released just one month later, along with support for newer hardware (camera flash, OpenGL 2.0 ES) it also added more Bluetooth profiles (up to that point Android phones could only interact with headsets) and a better Bluetooth API as well as Google Voice Search among others. If I remember correctly, this was mainly used by the Droid and no other phone at that time. It was Android 2.1 (also Eclair) that shipped these new features to phones from other manufacturers since January but not without adding some more features such as live wallpapers. HTC said they would skip 1.6 and go directly to 2.0/2.1 for the Hero. Android 2.1’s release date was timed with the release of Nexus One which was manufactured by HTC. Last week, Android 2.2 (Froyo = Frozen yogurt) was released, bringing (among others) WiFi and USB tethering without the need of rooting your device.

Sprint released a 2.1 update for their customized Hero last week, one week after another customized revision called “Droid Eris” got the update. Hero owners using the plain GSM phones (in contrast to CDMA by US operators) are still waiting in vain for a release. There were multiple release dates, both rumored and official, each cancelled a few days before or simply missed. According to phandroid.com HTC now has yet another release date for us: A first preliminary update should roll out someday in June and the final 2.1 update should follow “a couple of weeks later” which could easily mean July or August regarding their previously announced dates. HTC also said, that 2.2 would come to all phones released in 2010 – that excludes the Hero for now…

Actually, Google released Android 1.6, 2.0 and 2.1 much too fast for any manufacturer to keep up with in time, that’s true. Also, HTC’s custom UI called Sense has to be ported to each Android revision they release an update for. But HTC already released a phone running Sense on 1.6. So assuming, they stopped support for Sense@1.5 at latest in November, they now had 6 months to tinker at ports to newer Android versions and prepare an update for the Hero. And they did: Not only did Droid Eris and Sprint Hero get an update in the past weeks, they also released a lot of phones previously, developing even more. All have similar hardware and starting from the Hero all of their Android phones have Sense UI.

So why didn’t HTC release any 2.1 update for the Hero yet? Considering that at least the Sprint Hero could have had its update so “soon” only because the network operator Sprint may have built its own release, I’ve got the notion that HTC is building throw-away phones: If one gets outdated, just dispose it and buy a new one; maintenance will only run for a few months and then suddenly stops. This may have worked for conventional phones in the past but since smartphones run on a common operating system that is often maintained by another company, that’s the completely wrong path to keep the Android platform healthy and customers as well as developers satisfied. By healthy I mean that a device should usually support all public API levels until the hardware becomes insufficient which shouldn’t be that much of a problem with smartphones which are nothing but PDAs with a cellular radio chip. However, since Android is open source and modifications to the Linux kernel have to be published under GPL, Android phones should be open to custom upgrades and so is the HTC Hero.

Unfortunately I’m legally unable to link or name any of the custom ROMs I’ve found but if you do a standard Google search you will most likely find them quite easily. They either run the plain Android system or incorporate (pirated) copies of Sense UI from leaked or previously released images. Since I’m not the only one who is sick of HTC’s poor excuses, there seems to exist a variety of ROMs specifically targeting the Hero. Reading into what’s necessary to get an update, I’ve found out that HTC is actually making it difficult to flash an inofficial ROM onto the phone. This involves unlocking a special diagnosis mode and signed files; things I would not have expected at all from a badly maintained open source based phone! Although I didn’t try it myself, it seems like even versions containing ripped Sense binaries run surprisingly fine (with some minor bugs and inconveniences) on the Hero, so the question remains: Why does HTC delay updates if a community of a few unrelated developers is able to build almost completely working releases?

To make things worse, it seems like at least a few released 2.1 images introduced a jail lock that appears to not have been broken completely yet. So you are strongly advised to check the news on this topic before installing any official HTC updates from now on or you may not be able to ever go further than Android 2.1.

Why does this happen? What are they thinking? I start to regret having bought my Hero with the wrong expectation to have a modifiable phone that doesn’t outdate for a few years due to an evolving open source operating system. All I can do now is to warn other people from buying HTC’s phones without prior investigation of possible issues. While other Android phones may also be several months late lagging behind Google’s SDK releases, that may be excusable up to some point (especially since Google sprinted ahead with their releases since 1.6). The day the Hero finally receives its 2.1 update, other phones will already get their updates to 2.2 and I doubt HTC will continue to update the Hero further. Since a jail lock may be introduced to the normal Hero by the preliminary update in June I would strongly advise considering either getting a custom ROM instead or live with 1.5 and wait for more information (is HTC serious about 2.1 and will the Hero get 2.2?). Once you installed that update you may not be able to go further without buying a new phone although the hardware would be capable of it. All I know for sure is that I won’t buy another HTC phone in near future.

As of May 17, Android currently has an almost equally distributed version fragmentation across 1.5, 1.6 and 2.1. In the advent of 2.2 and the final updates to 2.1 I would expect that we are one or two months from finally calling 1.5 (the third API level) “legacy”. This means that the number of devices running 1.5 will drop significantly low and therefore less and less applications will run on 1.5 due to API updates more current applications may prefer to use (with Android 2.2 we have reached API level 8). The 34,1% share of Android 1.5 may in fact contain a large percentage of Heros since almost every other phone has had updates and the Hero sold pretty well. Developers have or will have to choose whether they want to maintain a legacy “Hero revision” of their software or not. Thus by holding back OS updates, HTC is not only upsetting its customers but is annoying developers as well, so its highly unlikely they will support a 10% or less share of 1.5 users. Running out on updates in less than one year isn’t what Android was meant to be nor what I would expect from a 400€ device.

reinstalling KDE

I was still using the unstable KDE 4.2 until this weekend. For some strange reason, the slotted 4.2 ebuilds were completely removed from portage, thus preventing any re-merges which I had to do since I wanted to also upgrade from GCC 4.1.2 to 4.3.4, so I had to uninstall KDE before, upgrade GCC, recompile everything, then finally merge KDE again. To remove KDE more or less completely I was told to do emerge -pCv $(qlist -ICv kde | grep 4.2) (minus the pv of course). I had some other ebuilds left for manual checking but this command caught the vast majority. Unmerging and remerging kde-meta (after the GCC upgrade) went really smooth. To have a WM in the meantime I emerged xfce4-meta and gnome-terminal before I unmerged KDE.

Akonadi migration with bogus entry

Recently I had issues with some corrupted config in Akonadi that could not be solved from within KDE 4.2. On every start I would now get the migration dialog retrying to migrate a bridge called Y2252jgYO7 – whatever that was, I couldn’t find it. Running locate on that ID revealed old lock files back from KDE 3.5. Having searched for a moment I figured out that I could simply find and remove the files:

find ~/.kde* -iname \*Y2252jgYO7\* -exec rm \{\} \;

Next, everything referencing that ID has to be removed from ~/.kde4/share/config/kres-migratorrc – redo whatever runs the migration assistant for you and the problem should be solved.

frenzy Nepomuk – again…

I don’t seem to be the only one where the desktop search never works. With KDE 4.2 I disabled Strigi and Nepomuk because it took 100% CPU even when idling. If it wasn’t idling it was accessing the harddisk way too fast and so it always slowed down my system. That wasn’t without sideeffects however: I was unable to use the runner (Alt+F2) without crashes. I figured out that enabling Nepomuk, disabling Strigi and removing all repository data worked in KDE 4.2. Guess what? The problem reappeared after the upgrade to KDE 4.3. I don’t know if I solved it “properly” (I don’t need desktop search ATM so I can afford disabling it). From Stéphane Laurière at Mandriva’s bug tracker:

1. make a backup of your Nepomuk database by backuping the folder ~/.kde4/share/apps/nepomuk/repository/
2. reconfigure Strigi from the Nepomuk System Settings so that it indexes less
   folders
   Note: I unchecked everything plus added * to the exclude patterns, just to be sure.
3. stop Nepomuk by running the following command:
   qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit
4. remove the repository folder ~/.kde4/share/apps/nepomuk/repository/
5. restart Nepomuk: nepomukserver

After restart I got several crashes (what else) but Nepomuk stops retrying after a short time… (you should watch out for large numbers of crash logs though)

the Cashew

If you ever wondered what the name for that moon-and-star-like icon is which you get when unlocking your panels in KDE4, it seems to be called “the Cashew”. I know there was one icon on the desktop when I started using KDE 4.2 but it somehow disappeared very soon on its own and I didn’t miss it. It seems like that has been some bug since I now had it again:

That nasty icon was sitting right on my otherwise clean desktop wallpaper. I could move it around my screen borders but it could not be removed. I thought something was broken until I finally searched for it and figured out that it’s some kind of branding not be meant to be removed. Great… Now, how do you get rid of it?!

As pointed out on the Gentoo forums (thread “KDE 4.3.0 Annoyances“) and also on a blog post, there exists a plasmoid that you can simply drop onto your desktop to remove/hide that useless cashew: I HATE the Cashew

If you should ever want that apparently useless cashew icon back, simply remove “I HATE the Cashew” by clicking the minus icon on the “Add Widgets” dialog.

There used to be an ebuild for it but since I couldn’t find it I simply wrote one on my own (well, half-way copy&pasting from other ones and the ebuild documentation, but it works). In case you need it too, here it is: (kde-misc/ihatethecashew-0.4)

# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

MY_PN=iHateTheCashew

DESCRIPTION="I HATE the Cashew - KDE4 corner icon removal plasmoid"
HOMEPAGE="http://www.kde-look.org/content/show.php?content=91009"
#SRC_URI="http://www.kde-look.org/CONTENT/content-files/91009-${MY_PN}-${PV}.tbz"
SRC_URI="http://www.kde-look.org/CONTENT/content-files/91009-${MY_PN}-4.4.tbz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""

S=${WORKDIR}

src_unpack() {
        unpack ${A}
}

src_compile() {
        cd iHateTheCashew
        mkdir build
        cd build
        cmake -DCMAKE_INSTALL_PREFIX=/usr .. || die "CMake failed!"
        emake || die "Make failed!"
}

src_install() {
        cd iHateTheCashew/build
        emake DESTDIR="${D}" install || die "Install failed"
}

 * This package will overwrite one or more files that may belong to other
 * packages (see list below). You can use a command such as `portageq    
 * owners / <filename>` to identify the installed package that owns a    
 * file. If portageq reports that only one package owns a file then do   
 * NOT file a bug report. A bug report is only useful if it identifies at
 * least two or more packages that are known to install the same file(s).
 * If a collision occurs and you can not explain where the file came from
 * then you should simply ignore the collision since there is not enough 
 * information to determine if a real problem exists. Please do NOT file 
 * a bug report at http://bugs.gentoo.org unless you report exactly which
 * two packages install the same file(s). Once again, please do NOT file 
 * a bug report unless you have completely understood the above message. 
 *                                                                       
 * Detected file collision(s):                                           
 *                                                                       
 *      /usr/bin/maildirmake                                             
 *      /usr/share/man/man1/maildirmake.1.bz2                            
 *      /usr/share/man/man8/deliverquota.8.bz2                           
 *                                                                       
 * Searching all installed packages for file collisions...               
 *                                                                       
 * Press Ctrl-C to Stop                                                  
 *                                                                       
 * mail-filter/maildrop-2.2.0                                            
 *      /usr/bin/maildirmake                                             
 *      /usr/share/man/man1/maildirmake.1.bz2                            
 *      /usr/share/man/man8/deliverquota.8.bz2                           
 *                                                                       
 * Package 'net-mail/courier-imap-4.5.0' NOT merged due to file          
 * collisions. If necessary, refer to your elog messages for the whole   
 * content of the above message.                                         

maildrop belongs to courier and although that collision isn’t great but won’t hurt being ignored, I added the following line to /etc/make.conf (wrapped to be readable on my blog):

COLLISION_IGNORE="/usr/bin/maildirmake \
 /usr/share/man/man1/maildirmake.1.bz2 \
 /usr/share/man/man8/deliverquota.8.bz2"

This will permanently ignore the collision for all 3 files.

Searching the internet we found out it must be a problem with the drive’s host protected area (HPA) in conjunction with his mainboard/SATA controller (ironically from Gigabyte). He updated BIOS and chipset drivers but the problem persisted. According to some forums there are some tools for Windows to fix that issue. Since many people reported data loss afterwards and he didn’t have another copy of the data he moved from his external drive we decided to boot into the new Gentoo Live DVD that also allowed me to log in remotely via SSH to investigate the problem (we are more than 500km away from each other).

Following a short guide on how to detect and disable HPA we could see the settings of his drive:

# hdparm -N /dev/sdb
/dev/sdb:
 max sectors   = 65134/1953525168, HPA is enabled

This seems to have been the opposite configuration of what should have been set according to the guide: While the examples from the guide had a much greater value before the slash his drive seemed to show the intended remainder to be allocated to the HPA set for “public” use, so his HPA seemed to cover almost the entire 1TB of his HDD.

Before we tried to correct that value we wanted to check if we can access any data right away. Unfortunately everything prevented us from accessing the HPA – the kernel did only register /dev/sdb1 but not /dev/sdb2, smartmontools showed 33MB capacity as well, parted refused to work and fdisk finally showed the correct partition table but reported a mismatch in geometry, so at least we still seemed to access the same start sector of his HDD:

Disk /dev/sdb: 33 MB, 33348608 bytes
255 heads, 63 sectors/track, 4 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x24c2a85c

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       38245   307200000    7  HPFS/NTFS
Partition 1 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(38244, 193, 29)
/dev/sdb2           38245      121601   669558784    7  HPFS/NTFS
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(1023, 254, 63) logical=(38244, 193, 30)
Partition 2 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(121600, 247, 55)

We also tried to access /dev/sdb with dd but only got the 33MB until the drive “ended”. Considering the HPA modifications to be the last resort we tried to change it only temporarily at first, but had to set it permanently to get any effects on the system after a reboot. Please note that the manpage for hdparm explicitely states that changing that setting is “VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY”. I copied the old value to a text editor before making the modifications, so I hoped we could at least set it back to what it was before our changes in case it didn’t work well. To make a permanent change, simply run the same command with p (for permanent) followed by the new maximum value to be set (to disable HPA this would be the exact same value as written after the slash):

# hdparm -N p1953525168 /dev/sdb

Having rebooted, fdisk did not complain any more and the kernel recognized both partitions:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x24c2a85c

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       38245   307200000    7  HPFS/NTFS
/dev/sdb2           38245      121601   669558784    7  HPFS/NTFS

hdparm confirmed that we just disabled HPA:

# hdparm -N /dev/sdb

/dev/sdb:
 max sectors   = 1953525168/1953525168, HPA is disabled

We mounted his data partition read-only using ntfs-3g and since everything seemed fine we started to copy everything back to his external drive, just to be sure we had a backup of his data in case that Windows would decide to crash his partition after another reboot. However, Windows Vista did recognize the drive correctly again and so did Windows 7; he can access all data and nothing seems to be corrupted or missing.

It appears strange that Windows initially ignored the HPA and worked well until he rebooted. But having had extreme, sporadic problems myself using a Silicon Image SATA controller with Windows XP SP2 as well as Windows Vista (without SP, back in 2007) it did not really surprise me any more.

Due to compile errors on many ebuilds I decided to run a revdep-rebuild. After about an hour it recognized that about 380 ebuilds were broken and had to be remerged. I began but could not finish that day so I left revdep-rebuild (which happened to stop due to an error anyway) and shut my system down.

The next day I realized that about half my system was broken. CUPS crashed repeatedly, reporting a segfault with libc whenever I tried to print anything (visible in the kernel log). Remerging cups or glibc did not help, so I went to the Gentoo forums and found the advise to run

emerge -e system 
etc-update 
perl-cleaner all 
python-updater 
emerge -1 libtool 
revdep-rebuild

It took a long time involving the usual stop-and-go caused by build errors but finally it finished. CUPS worked again and so did most of the system. Unfortunately 64 bit binaries like nxclient still did not run because libjpeg.so.62 did not exist any longer. Well, it did for 32 bit apps (so the 32 bit Firefox binary could still run) but not for 64 bit. (the 32 bit version is belongs to app-emulation/emul-linux-x86-baselibs) As usual, linking to the 32 bit library was without success (wrong ELF architecture) and linking to libjpeg.so.7 didn’t work well (I was able to run NX but all JPEGs were missing).

I was lucky enough to find a rather unrelated bug report on the bugtracker that indicates there is a second ebuild for libjpeg called media-libs/jpeg-compat which actually contains the missing 64 bit version of libjpeg.so.62. Having emerged that everything works fine again now.

Maybe I was always upgrading/updating at the wrong time – there is one thing I can read from the filenames portage downloaded:

opera-10.00-b1.gcc4-shared-qt3.x86_64.tar.bz2
opera-10.00-b3.gcc4-qt4.x86_64.tar.bz2

It seems like older versions have only been built (or downloaded) with Qt3 libraries but with beta 3 there finally is a Qt4 version available. Maybe that’s the fix – finally, after 2 years, I can use Flash again in my primary browser!

I checked some websites and while all Flash movies run and most run fine, videos still run jerky, highly depending on the players being used and the mode (fullscreen is worst). While these performance problems happen to be worse than in Firefox, it’s still mainly a problem of the Linux version of the Flash player (xkcd made a cartoon about it recently).

The next thing I could not use since I switched to 64 bit was the Java plugin. It was the same as with Flash, I got freezes and/or crashes and no useful error messages. I was quite surprised when I saw a useful backtrace on my terminal: For some reason, Opera 10 tried to use Blackdown JDK 1.4 which some ebuild must have had as a dependency. I unmerged it and now I got errors complaining about libjvm.so not being found. To point Opera to the correct path simply go into Tools/Preferences/Advanced/Content, enable Java and open the Java Options dialog. The path to be entered can be found by running locate libjava.so and should be something like /opt/sun-jdk-1.6.0.15/jre/lib/amd64/ (excluding the filename; you will need to update this on version changes).

On Gentoo you may still get an error message telling you that libjvm.so cannot be found. You may need to symlink it from …/jre/lib/amd64/server/ to …/jre/lib/amd64/ and it should be working after a browser restart.

I don’t know since when there was a Java Options dialog, so maybe I could have been able to use Java for quite some time now. Anyway, it’s great to finally have both plugins working again.

DO NOT TRY THE FOLLOWING STEPS ON A PRODUCTIVE SYSTEM!

Read all instructions carefully. I’m not responsible for any data loss or corruption you may experience by following this howto and using the patched MySQL or beta release of Amarok.

You may want to backup your databases before you go into patching. You have been warned (although everything seems to be fine on my system).

Patching MySQL
When I got it working yesterday, I still patched the eclass file to add a USE-flag “pic” for triggering a GCC option. The current status from the bug comments is that it should be a false solution and not be necessary anymore. However, I still get a linker error “recompile with -fPIC” when compiling Amarok 2 afterwards. So you still need to patch the eclass file using the files stroken out on the bug report (mysql.eclass and a patch to it, apply the patch or grab the resulting file here). You may want to try if it works for you without the patched eclass, though. If you choose to apply the patched eclass, you need to put it in your overlay into /eclass directory (top-level like a category). On the next emerge you will be warned to add “metadata-transfer” to your FEATURES variable in /etc/make.conf and run emerge –regen after each sync (this will take a while; ~20 minutes on my 3GHz Core2Duo).

Now we need an ebuild, too. Download the patch file to MySQL’s source code (better check if it’s still current) and store it in your local overlay’s dev-db/mysql/files. Copy the latest ebuild for MySQL from official portage to your overlay and rename it to match version numbers with the patch. Run ebuild mysql-whateverversion.ebuild digest, unmask and emerge it! (using “embedded” USE-flag)

Amarok 2.1 Beta 1
If we go unstable, we do it right. So we are going to create an ebuild for Amarok 2.1 Beta 1, too. Again, BE WARNED: There are some possible corruption issues with ID3 tags (also reported for 2.0.1). You don’t want that to happen, so be careful not to do any writing operations to your files in Amarok until that bug gets fixed. (I got a couple more with reading tags but my files are still intact, so I’m fine; all bugs are already in the bug tracker)

Amarok 2.1 depends on taglib-extras, which is currently not in portage. So simply go to http://gpo.zugaina.org/media-libs/taglib-extras and grab 0.1.2’s ebuild, put it in overlay, digest, unmask and emerge.

For Amarok itself, Beta 1 seems to be version 2.0.90. Simply grab my ebuild, which is a slightly modified version from official portage tree. I removed the iPod patch and the webkit string replacement, added 2 dependencies and had to fake the check for Qt script bindings. Of course, I needed to replace the download URI and add ~amd64 keyword:

--- /usr/portage/media-sound/amarok/amarok-2.0.1.1.ebuild       2009-03-16 11:36:10.000000000 +0100
+++ amarok-2.0.90.ebuild        2009-04-12 17:53:18.000000000 +0200
@@ -14,10 +14,11 @@
HOMEPAGE="http://amarok.kde.org/"
LICENSE="GPL-2"
-KEYWORDS="~x86"
+KEYWORDS="~x86 ~amd64"
SLOT="2"
IUSE="daap debug ifp ipod mp3tunes mp4 mtp njb +semantic-desktop"
-SRC_URI="mirror://kde/stable/${PN}/${PV}/src/${P}.tar.bz2"
+#SRC_URI="mirror://kde/stable/${PN}/${PV}/src/${P}.tar.bz2"
+SRC_URI="ftp://ftp.kde.org/pub/kde/unstable/${PN}/${PV}/src/${P}.tar.bz2"

DEPEND=">=app-misc/strigi-0.5.7
|| (
@@ -25,6 +26,8 @@
>=dev-db/mysql-community-5.0[embedded,-minimal]
)
>=media-libs/taglib-1.5
+       >=media-libs/taglib-extras-0.1
+       >=x11-libs/qt-script-4.4.2
|| ( media-sound/phonon x11-libs/qt-phonon:4 )
>=kde-base/kdelibs-${KDE_MINIMAL}[opengl?,semantic-desktop?]
>=kde-base/plasma-workspace-${KDE_MINIMAL}
@@ -46,7 +49,8 @@
app-arch/unzip
daap? ( www-servers/mongrel )"

-PATCHES=( "${FILESDIR}/${PV}-ipod.patch" )
+# PATCHES=( "${FILESDIR}/${PV}-ipod.patch" )
+PATCHES=( )

pkg_setup() {
if use amd64 ; then
@@ -77,9 +81,10 @@
fi

# Remove superfluous QT_WEBKIT
-       sed -e 's/ -DQT_WEBKIT//g' \
-               -i "${S}"/src/scriptengine/generator/generator/CMakeLists.txt \
-               || die "Removing unnecessary -DQT_WEBKIT failed."
+#      sed -e 's/ -DQT_WEBKIT//g' \
+#              -i "${S}"/src/scriptengine/generator/generator/CMakeLists.txt \
+#              || die "Removing unnecessary -DQT_WEBKIT failed."
+       sed -e 's/CHECK_CXX_SOURCE_RUNS/set( BINDINGS_RUN_RESULT 1 )\n#/g' -i "${S}"/cmake/modules/FindQtScriptQtBindings.cmake

mycmakeargs="${mycmakeargs}
$(cmake-utils_use_with ipod Ipod)

You may need to uninstall Amarok 1 before emerging 2 or you will get file collisions.

Some problems
I have 2 soundcards and Amarok was playing everything on the wrong one on first start-up although I reordered my cards in the configuration dialog. I seem to have gotten rid of that problem by simply restarting Amarok after changing the order. GStreamer backend currently crashes, so you may prefer xine (which I do nevertheless).

I couldn’t get Ampache working yet, but I assume the fault is on Ampache’s side. We were able to track the problem down, likely being the hash being used on authorization which seems to be an issue between 32 bit servers and 64 bit clients (seems to be a different timestamp; I really don’t know why that’s still a problem, I guess it’s very bad programming or at least testing…).

Amarok doesn’t index all files correctly. Some files are not shown with metadata but only with their filenames instead. You may be able to work around it by rescanning your collection multiple times. There also seem to be some index issues on the collection when updating the collection while browsing through it. However, I still got some MP3s not showing up in my collection although they seem to be counted.

Oh, and you scrobble streams to Last.fm which I consider a bug since that’s not the intended behaviour (or at least has not been until now).

I will try to confirm these bugs and report them if they are not already listed in KDE’s bugtracker.

Some scripts currently don’t work. That’s because we faked around the script bindings dependency in order to be able to compile. You may get some ebuild to compile qtscriptgenerator, but it depends on Qt 4.5 which I haven’t yet installed (yes, I know I blogged about the recommendation to use it one post earlier, but I haven’t had time to recompile it yet – I should do that next). Do not report errors about scripts not running to Amarok devs; it’s entirely our own fault. However, if you need those scripts, you are free to get into compiling that dependency as well.

Make it prettier
Amarok’s default theme doesn’t look appealing, at least not when using KDE’s Oxygen theme with default colors. You may have a look at alternative Amarok themes on kde-look.org. Most themes inherit their colors from your color theme, so don’t be surprised if it looks different than on the screenshots. I went for “Amarok Highlights” for the time being.

Unfortunately, Amarok 2 is still lacking a theme manager, so you have to install the themes manually by copying them to ~/.kde4/share/apps/amarok/images/ (one at a time; stylesheet.css goes one level above). You should quit Amarok before changing themes and clean caches before restarting it:

rm ~/.kde4/cache-YourHostname/kpc/Amarok-pixmaps.index
rm ~/.kde4/cache-YourHostname/kpc/Amarok-pixmaps.data