I plan to later use uscan for simplifying package updates in some
NixPkgs packages. I have no code for that now.
I added Perl packages File::DesktopEntry and File::BaseDir in a slightly
hascky way because one part of the installation system replaced PREFIX=
with --prefix= and the other complained that it doesn't know what to do
with --prefix=. I checked that a script using File::DesktopEntry works,
and I don't know enough Perl to rewrite buildPerlPackage and hope that
my change is an improvement.
I removed trnaslated manpages because it uses po4a which has some more
Debian-specific dependencies of its own.
As well as for neko, we now have way less cruft within the mkDerivation
attribute set. We also now use make to build haxe, which will include haxelib
and haxedoc as well.
The main reason why I was doing this was because the package didn't build and
still was referencing mawercer.de, which does not contain those tarballs
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should simplify the input of the derivation builder significantly and of
course we don't need to rely on mawercer.de to supply the needed files. Also,
the derivation name doesn't include "-cvs" anymore, as we're building from the
release tarball.
In addition, we don't need the patch anymore, as it was so simple that it could
be done easily with sed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The openjdk BOOT_CYCLE bootstrap doesn't use the binaries built in the first stage for the second stage, so we get a bunch of errors like:
/bin/sh: /nix/store/wdgl7xl9b72hn212l0672ad5sn7vh44y-openjdk-bootstrap/bin/native2ascii: No such file or directory
Instead, just build each stage as a separate derivation
It seems the resulting output path has no reference to libxine, so it
does not get used. Probably it needs some hard-coded link-paths as
eaglemode wants to use dlopen for some things.
If anyone wants to use eaglemode's xine support and fix this issue,
please make it optional.
- big cleanup of optional dependency handling
I hope I didn't miss any cases.
- XVID
xvid support seams broken, both built-in as external.
I didn't notice any issues playing xvid video's though, as ffmpeg's
default mpeg4 decoder handles xvid-encoded files just fine.
It seems the only users affected by this are users who still encode
xvid with mencoder (instead of plain ffmpeg). If this really is an
issue to anyone, please let me know, so I can look into it some more,
or retain an older mplayer version next to this one.
