> Compiling source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999. > Configuring source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999. > Preparing source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999. > Source unpacked in /var/tmp/portage/games-action/oolite-9999/work * working copy: /usr/portage/distfiles/svn-src/oolite/trunk > Unpacking firefox-4.0. to /var/tmp/portage/games-action/oolite-9999/work * FEATURES: preserve-libs sandbox splitdebug * Maintainer: USE: elibc_glibc kernel_linux userland_GNU x86 > Verifying ebuild manifests > Emerging (1 of 1) games-action/oolite-9999 from rion Unfortunately, oolite-9999 fails to build due to this: Oolite is a game and doesn't use anything but the gnustep-base & gnustep-make. Would be nice if gnustep crowd produced some superset safe to use on top of gnustep-base without all those pesky deps from gnustep-2. In other words if at some point inheriting gnustep-base will break the fix is a simple replacement with "inherit gnustep-2". also inheriting gnustep-base does produce only the necessary library dependancies rather then pulling in things that are not needed (Gentoo's "minimalistic" philosophy kicks in ) ). Generic "strip" doesn't seem like a bad idea in that case.Īs for category entry - yes, I filed it on my system under games-simulation (which might not be the final destination for it) and it does work under KDE (sorry - can't atest for GNOME as I have none around).ĭependency on gnustep-2 is gone since it produced nasty side-effect of make_services crapping up on each and every login session on that machine (however if somebody merges gnustep-gui for whatever reason - it'll resurface again). Either that or fix make_services upstream (I wonder what's going to happen if machine is offline and DTD is un-fetch'able). This probably should be solved in gnustep eclasses - making sanitation "automatic" as it will produce errors with other XML plists as well - I'm 100% sure. Is there anything else to clean up to make it suitable for inclusion in portage?Īs for tags - it seems there's an error in make_services - it does download appropriate DTD but it downloads it into current directory however expects it in /tmp/ which well, smells like a bug if you ask me but it's a gnustep bug rather than oolite. > just call egnustep_env once in src_unpackĪll above - done. > create "$/oolite" in src_unpack and just install it in src_install > call prepgamesdirs at the end of src_install > remove the chgrp and chmod in src_install > remove the second, commented-out inherit line > move the closing " up to the end of the deps to match the style of all theĭone (although I think there's ppc build possible - have no hardware to test) list of dependencies is simplified now and should cover basic needs of package > virtual/x11 should go away - it doesn't exist anymore > It looks very suspicious to me that the sdl deps are on needed for x86. RDEPEND="x86? ( >=media-libs/libsdl-1.2.8-r1 )Īmd64? ( >=app-emulation/emul-linux-x86-sdl-2.3 )Īmd64? ( app-emulation/emul-linux-x86-libxml2 )Īmd64? ( app-emulation/emul-linux-x86-libxslt )Īmd64? ( app-emulation/emul-linux-x86-libart_lgpl )Īmd64? ( >= app-emulation/emul-linux-x86-xlibs )"įorgive me if I've written something patently absurd, but I'm a real newbie as far as ebuilds go (but I'm willing to learn). How can one do that? Is it correct to do something like the following? if built for x86, but on the corresponding emul-linux-x86 packages if built for amd64. In oolite-bin's case the package has to depend on libsdl, sdl-gfx, sdl-image, sdl-mixer, etc. Is there a way to specify different runtime dependancies depending on the architecture we're building for? I was trying to "extend" the ebuild to also cover amd64 systems (which need 32 bit versions of libxml, libxslt and libart_lgpl, see new bugs this one now depends upon), but I stumbled on a problem: Implemented changes suggested by gentoo-gnustep MLįigured out portable "cp" replacement to "tar" Updated version with full install and desktop/menu entry Requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |