The content of this post is deprecated, but still the message might be good to know

Today,  I stumbled upon TWO different issues in major projects of FOSS – within 1½ hour of physics lecture.

First One: I tried to compile Firefox for myself (as I do since v3.what-do-I-know, but since long enough). I already got some issues with the build process before, which I was able to fix with small changes in source code (see: http://blog.kiga-it.de/?p=28). But today’s issue is somewhat different: While building FF13 pre-release (and before, it was the same story with FF13b4), the build process broke down after only several minutes, with the following error message:

*** No rule to make target »../../../xpcom/idl-parser/xpidl.py«, needed by »libs«. Stop.

Afterwards, I tried with installing python-xpcom. And yes, it helped – somehow. But then, I came across this:

make[5]: Entering directory `~/dokumente/src/mozilla-release/xpcom/idl-parser'
make[5]: *** No rule to make target »header.py«, needed by »export«. Stop.
make[5]: Leaving directory `~/dokumente/src/mozilla-release/xpcom/idl-parser'
make[4]: *** [export] Fehler 2
make[4]: Leaving directory `~/dokumente/src/mozilla-release/xpcom'
make[3]: *** [export_tier_platform] Fehler 2
make[3]: Leaving directory `~/dokumente/src/mozilla-release'
make[2]: *** [tier_platform] Fehler 2
make[2]: Leaving directory `~/dokumente/src/mozilla-release'
make[1]: *** [default] Fehler 2
make[1]: Leaving directory `~/dokumente/src/mozilla-release'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary] Fehler 2

and just thought “What the hell is wrong with those Mozilla guys?” (In fact, it doesn’t seem like a problem with my installed dependencies, but more like an ambiguous MakeFile with (maybe) missing rules, or something like that….

Second One: Afterwards, I wanted to clear my angry head – of course not by listening to the lecture, but by playing supertuxkart for  short while. But wait, why doesn’t the game start as it should. A look at the terminal window et voila, libIrrlicht-1.7a.3 is missing. A missing binary? In a build for Debian testing? How the HELL did they manage to bypass the version control, made up exactly for something like that NOT to happen? (I’ve checked it twice, the debian testing repositories do only provide supertuxkart listed with a dependency on libIrrlicht-1.7a, but it is LINKED against libIrrlicht1.7a.3, latest version available in the repositories is libIrrlicht1.7a.2)

I was able to play the game after creating a softlink within /usr/lib/ (didn’t run THAT stable,  it lasted for some minutes each start), but I still couldn’t compile my browser.

And what do we learn? NEVER let your project grow as big as Firefox or Debian, it definitely will carry it’s flaws then!

Update1: The Debian Bug-Tracking-System files Bug #675929, and has marked as serious. Goog News: It seems as if a solution is to be expected in a short time.

Update2: It seems, as if the Debian-Team has updated libIrrlicht-1.7a to contain libIrrlicht-1.7a.3, but the game still runs unstable for me due to many “bus errors”

Update3: At the mozilla bugtracking system, you can find a patch that seems to solve the FIRST Firefox-issue, but still, building header.py for export fails – hope that FF14 will fix that bit…

Update4: Yay! Seems as if the problem is fixed 😉 One “just” has to apply the patch proposed at the bugtracking system, or manually needs to edit the $topsrcdir/xpcom/idl-parser/Makefile, where an option “–cachedir=.” needs to be changed to “–cachedir=cache”, i.e. After that, it runs (due to the wrong cache, the files header.py and idl-parser.py within that directory have been deleted after the Makefile has been called the first time, which stopped it a the second time)