This bug is for comments on the new split ebuilds. I am hoping to get some user testing on these before taking them out of package.mask for general usage. You can test this ebuild set by doing the following: mkdir -p /etc/portage echo "games-rpg/nwn" >> /etc/portage/package.unmask echo "games-rpg/nwn-data" >> /etc/portage/package.unmask echo "games-rpg/nwn ~x86" >> /etc/portage/package.keywords echo "games-rpg/nwn-data ~x86" >> /etc/portage/package.keywords emerge nwn Now, if you're on an amd64 machine, replace ~x86 with ~amd64 above.
One small problem.. nwn-data installs happily however I get this warning during nwn install. I've resynced to check it wasn't in portage. ------ sed: can't read /usr/portage/games-rpg/nwn/files/nwn-1.66-fixinstall: No such file or directory ------ My other comment would be to be more specific with this message. I thought, first time, that you meant the nwn discs not the expansion discs. * This package will need access to 2 cds. All good though :-)
(In reply to comment #1) > sed: can't read /usr/portage/games-rpg/nwn/files/nwn-1.66-fixinstall: No such > file or directory I've fixed this in portage now. Sorry about that. > My other comment would be to be more specific with this message. I thought, > first time, that you meant the nwn discs not the expansion discs. > * This package will need access to 2 cds. That message comes from an eclass and can't really be changed. I've added some code to make it display the information, though. Feel free to emerge sync (in 30 minutes or so) and try the nwn ebuild again. There's no reason to redo nwn-data, since all I did was add a couple "echo" statements in to tell the user which CD they'll need.
*** Bug 107255 has been marked as a duplicate of this bug. ***
Just some initial feedback whilst the files are downloading: If I use "hou nowin sou", the patches for hou and sou are downloaded. If I were to patch manually, it's my understanding that only the hou patch is needed. If I'm correct, could this be rectified ? - An extra 100mb is an extra hours of downloading for some people :)
Actually, both patches are required. Bioware's pages are actually incorrect.
(In reply to comment #5) > Actually, both patches are required. Bioware's pages are actually incorrect. In that case, I'll proceed with the download :)
Seems to work well, great job! However if I run fixinstall: chmod: cannot access `/opt/nwn/data/patch.bif': No such file or directory chmod: cannot access `/opt/nwn/patch.key': No such file or directory
Those files are actually removed on purpose if you've installed sou or hou, so that isn't an error. I'll edit the fixinstall to /dev/null those error messages, though.
*** Bug 75397 has been marked as a duplicate of this bug. ***
*** Bug 75399 has been marked as a duplicate of this bug. ***
>>> Install nwn-data-1.29 into /var/tmp/portage/nwn-data-1.29/image/ category ga mes-rpg /usr/portage/games-rpg/nwn-data/nwn-data-1.29.ebuild: line 108: cd: ambient: No such file or directory /usr/portage/games-rpg/nwn-data/nwn-data-1.29.ebuild: line 108: cd: data: No suc h file or directory /usr/portage/games-rpg/nwn-data/nwn-data-1.29.ebuild: line 108: cd: localvault: No such file or directory /usr/portage/games-rpg/nwn-data/nwn-data-1.29.ebuild: line 108: cd: music: No su ch file or directory chmod: cannot access `/var/tmp/portage/nwn-data-1.29/image///opt/nwn/data/patch. bif': No such file or directory chmod: cannot access `chmod': No such file or directory chmod: cannot access `a-x/var/tmp/portage/nwn-data-1.29/image///opt/nwn/patch.ke y': No such file or directory chmod: cannot access `/var/tmp/portage/nwn-data-1.29/image///opt/nwn/localvault' : No such file or directory
Could you provide some more information, like your emerge info and the USE flags used to install the game? Nevermind... I see that you probably used USE="-nowin" when installing. I've updated the ebuild in portage. Can you try the newer one?
Sorry. I did use the nowin option. But I still seem to get a game freeze while playing for about 3 min. I have noticed that the emerge of r1 has made some improvement, but not fixed that problem for me. I tried running the command from command line but get no errors, and I get no errors in my dmesg.
(In reply to comment #5) > Actually, both patches are required. Bioware's pages are actually incorrect. Their instructions have never failed me before. I have both SOU and HOU and I have only ever downloaded the HOU patch. If you don't mind, could you explain exactly why we need all three patch files (or point me to a bug that does)?
Works well here on x86, except for one minor thing: fixinstall is installed without execute permission. One feature that would be nice to have is nwmouse integration in the ebuild, as the game is almost not playable without it. I'll try and see if I can hack something up and submit it here.
(In reply to comment #15) > Works well here on x86, except for one minor thing: fixinstall is installed > without execute permission. Fixed. > > One feature that would be nice to have is nwmouse integration in the ebuild, as > the game is almost not playable without it. I'll try and see if I can hack > something up and submit it here. I have never heard of "nwmouse" and my game works perfectly fine.
> I have never heard of "nwmouse" and my game works perfectly fine. nwmouse can be found here: http://home.woh.rr.com/nwmovies/nwmouse/ Not much explanation, but very useful. It adds hardware cursor support. You might have noticed that the mouse cursor in NWN is kind of slow, at least slower than in other applications. That's because it is drawn in software. nwmouse extracts all cursor images from game data, converts them to X cursors, and patches the game binary on load (through LD_PRELOAD) to use them. What I meant by "almost not playable without it" is that I would never want to go back to using the software cursor. I installed 1.66-r1 yesterday with LINGUAS="fr", and everything works perfectly well. Congratulations for such a good ebuild. Adding nwmouse was easy, so I should be able to propose a patch with a "nwmouse" USE flag shortly.
Interesting. Be sure to include the dependency, libelf, if USE=nwmouse... I guess I never noticed the software cursor being slow because my framerates are very high on my machine. At any rate, it sounds like something that would be useful to add.
Ok, the simplest seems to be to make a new ebuild for nwmouse, and to patch /opt/nwn/nwn in the nwn-data ebuild. I need to extract the cursors from the game data (installed by nwn-data) in src_compile(). However, as the portage user (I'm using userpriv and usersandbox in FEATURES) isn't part of the games group, it can't access it. What's the solution to this?
If you look on that page, he provides the cursors already extracted, so no need to read the data. I would suggest adding a "nwmouse" USE flag to both nwn-data and nwn. The first, applying the patch to /opt/nwn/nwn, and the second, having a RDEPEND on nwmouse ebuild. This way we pull in nwmouse for nwn, and not nwn-data, since nwn-data should probably never be updated by a user once it is installed. It also allows for the nwmouse version to be tracked independently of either of the other ebuilds.
Here's a patch to nwn-data-1.29.ebuild that is needed for nwmouse to work (see bug 109619). It adds a few environment variables, and loads the nwmouse.so dynamic library before running the nwmain binary, but only if the library was found (i.e. nwmouse is installed). --- nwn-data-1.29.ebuild 2005-09-30 03:35:39.000000000 +0200 +++ nwn-data-1.29-r1.ebuild 2005-10-17 22:55:14.000000000 +0200 @@ -87,6 +87,14 @@ unzip -o ${CDROM_ROOT}/Language_data.zip unzip -o ${CDROM_ROOT}/Language_update.zip fi + sed -i -e '\:^./nwmain .*:i\ +if [[ -f ./nwmouse.so ]]; then\ + export XCURSOR_PATH="$(pwd)"\ + export XCURSOR_THEME=nwmouse\ + export LD_PRELOAD=./nwmouse.so:$LD_PRELOAD\ +fi\ +' "${S}/nwn" + } src_install() {
Re. comment #20: yes, that's what I finally did. I'm not sure about the licensing issues though, basically the icons are copyrighted work, and I doubt the author got explicit permission to put them on his website. I would still be interested to know how to solve this problem of not being able to access /opt/nwn due to not being in the games group. All the data to generate the cursors is available, so I feel this would be the proper way to go. The nwmouse USE flag in games-rpg/nwn sounds like a good idea. But no need to add it to games-rpg/nwn-data, as the /opt/nwn/nwn script can autodetect if nwmouse is available or not.
Yeah, I saw how you did that and I've already added it to the nwn-data ebuild... ;]
I would like to see per user settings as an option in the new ebuild. So that users have their all their nwn settings stored in their home directories. Something like what is mentioned in bug #83291 would be nice. http://bugs.gentoo.org/show_bug.cgi?id=83291
http://www.gentoo.org/proj/en/desktop/games/#doc_chap5_sect10 That doesn't have anything to do with getting these ebuilds tested in any way, but thanks for your input. I'm well aware that it has been requested, because, well, there's a bug requesting it. Asking for resolution of another bug on this one isn't exactly helping anyone but does increase bug spam. Now, to keep this response from being a complete waste... ;] I updated the ebuilds yesterday to hopefully make them work properly for people with a Windows installation that are not using USE="nowin", so I need that tested. I don't have any copies of Windows around to be able to test. Once I am sure that the ebuilds are completely functional for doing the base installations, then I'm going to look into adding the requested features.
err.. sorry :/ Anyway, with these ebuilds is there any possibility of having the user copy the SoU and HoU files into distfiles, or having the ebuild automatically copy them the first time, so that the cds (or dvd) are not always needed when having to update or reinstall?
That's the whole point of splitting the ebuilds. The "data" ebuild never gets updated (once it gets unmasked and is finalized, of course.) All of the patches will go into the "nwn" ebuild. And no, there's no way to copy it to distfiles, nor will there be. You're more than welcome to copy the files to some directory on your hard disk and use the CD_ROOT* variables that are standard with the CD-reading interface in the ebuild.
What if at some point I choose to perform an 'emerge -e world'? I don't want to have to wait for it to reach nwn-data with cds ready.
Welcome to the dilemma of interactive ebuilds. The basic answer. Tough. The long answer is that I would love some way to convince portage that an ebuild is interactive and allow it to be skipped. At any rate, that has *nothing* to do with this bug, which is for testing the ebuilds.
*** Bug 113530 has been marked as a duplicate of this bug. ***
Wow. I searched high and low and still somehow missed this bug completely. I won't test this ebuild because my game works perfectly after much work, so this is mainly a description of how I got it to work on my machine. Please use it in whatever way you think is necessary. First, the data *must* be installed before the game client. This is because the game client includes patches to the game data - and bioware does not support installing the client before the game data anyway. Besides which, not all game data will be the same. If, for instance, someone is using the DVD version of NWN Platinum, your ebuild won't work, as far as I can see. There's a slightly different install process for the DVD version: From the temporary directory, execute unshield /path/to/dvd/data1.cab unshield /path/to/dvd/data2.cab This creates the basic directory structure under NWN_Platinum. Next, execute these next commands from within NWN_Platinum unzip /path/to/dvd/Data_Shared.zip unzip /path/to/dvd/Language_data.zip unzip /path/to/dvd/Language_update.zip Download the latest patch at http://content.bioware.com/neverwinternights/linux/166/XXXX_linuxclient166_xp2.tar.gz Where XXXX is a language: English, German, French, Spanish, Italian !! This is the client *specifically* for Platinum !! Run ./fixinstall (You can see this here: http://nwn.bioware.com/forums/viewtopic.html?topic=391386&forum=72) Please also see the forum above to make sure we are installing the data files *correctly* - that is, in a way that's supported by BioWare. You can leave things out and have the game still run, yes, but it's not considered a "full install" by BioWare. The way described on the forum produces a match to the resource-data download. After all this is installed, we run the ./fixinstall script. Then we can install the game client. It's one-size-fits-all now (it used to be a muddled mess) so what we have works just fine. What follows below refer to the game client ebuild. Things like NWMouse and NWMovies really *really* need to be USE options in the ebuild because you would need to patch files in the nwn directory. And here is how to get NWMouse working: Extract the NWMouse archive: http://home.woh.rr.com/nwmovies/nwmouse/nwmouse-latest.tar.gz Grab and extract the latest cursors: http://home.woh.rr.com/nwmovies/cursors.tar.gz (Do this in the ~nwn/nwmouse/cursors directory - there are no paths stored) Execute ~nwn/nwmouse_install.pl to build the source code. Add these lines before 'nwmain' in the nwn script: export XCURSOR_PATH=`pwd` export XCURSOR_THEME=nwmouse export LD_PRELOAD=./nwmouse.so:$(LD_PRELOAD) There is also another great utility, called NWMovies. This is the hardest to get working right, but it can be done automatically: Emerge media-video/binkplayer (it simplifies things) Extract the archive into ~nwn: http://home.woh.rr.com/nwmovies/nwmovies/nwmovies-latest.tar.gz execute ~nwn/nwmovies_install.pl Modify the startup script to include: export LD_PRELOAD=./nwmovies.so:$(LD_PRELOAD) Before the 'nwmain'. (The LD_PRELOAD line needs to account for NWMovies and NWMouse at the same time. It's ugly, but it works.) We either *must* have libSDL with FEATURES="nostrip" installed on the system (in which case, we move the libraries in ~nwn/lib to a different location) or we need to have a new libSDL library. The reason is that libSDL *must* be compiled with ALSA support for movies to work in any enjoyable way. If we elect the second option, the ~libSDL/src/.lib/libSDL-1.2.so.x.x.x file goes to the ~nwn/lib direcroty and we change the link (libSDL-1.2.so.0) to point to it. We have to add "export SDL_AUDIODRIVER=alsa" to the nwn script before "nwmain" And a little "oopsie" in the newest release of NWMovies: we need to fix ~nwn/nwmovies.pl: $mplayer = qx{ which mplayer 2>/dev/null }; $plaympeg = qx{ which plaympeg 2>/dev/null }; -$binkplayer = "./BinkPlayer"; +$binkplayer = "BinkPlayer"; And we need to inform the user that if in-game sound does not work, they need to create either /etc/asound.conf or ~/.asoundrc to have: #/etc/asound.conf start: pcm.!surround71 { type plug slave.pcm "dmixer" } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:1,0" period_time 0 period_size 1024 buffer_size 4096 rate 44100 } bindings { 0 0 1 1 } } Now NWMovies will work like a charm. ;-) Provided you are using ALSA, of course. Here are the things needed to install NWN-Data: app-arch/unshield (if using the CDs) The game CDs *or* a download of the resource data. Here are the things needed to install the game client: A copy of NWMouse (and the cursors archive) and NWMovies media-video/binkplayer (if we want in-game movies) media-libs/libsdl with FEATURES="nostrip" *OR* a rebuild of libSDL in the game directory with ./configure --enable-alsa media-libs/sdl-gfx (If we want to make the movies fullscreen) dev-lang/perl (if we want either NWMouse or NWMovies) A language-specific download of the game client. And that's how I got my game working really well. If you install NWMovies, you might notice that the background music doesn't play during the initial titlescreen, but everything else works fine. Enjoy!
The ebuild fails to work with the Diamond Pack DVD. It will fail to detect the cds and when the cd_root variables are set to the DVD path it will appear to work, but it seems to be unpacking the various archives incorrectly and you end up with a broken install that segfaults when you attempt to play. I have now managed to get it working correctly by following the instructions here: http://nwn.bioware.com/forums/viewtopic.html?topic=457407&forum=72 and fiddling with some permissions which the ebuild already does.
I really don't think it's so excellent an idea to have a generic ebuild for nwn-data, simply because it's going to constantly break. It might be a better idea to have a virtual with use flags denoting the version desired, and possible a couple more for NWMOUSE and NWMOVIES, and the like. What do you think?
If I didn't think it was a good idea, I wouldn't take the time to do it. After all, it isn't like the current single monolithic ebuild is any better. Except it requires a complete reinstall every time. As for all of the people trying this on all of the other releases. IT IS KNOWN THAT IT ONLY WORKS ON THE ORIGINAL RELEASE CD. If you have a DVD or something, then it will not work for you. It does not check for any of the DVD releases, because I don't have them. Neither does the original ebuild that it replaces. If you would like support for your package, please file a separate bug, such as bug 88521 and set it as a blocker of this bug. As for nwmouse and nwmovies, there is an ebuild for nwmouse already. I have no problem adding support for nwmovies, except that it sounds like a big hack, and I dislike big hacks.
Please don't take my comment as a dismissal of your work or an incitement to an argument. I don't like having that done to me, and I certainly wouldn't do it to you. I definitely think an idea of a separate ebuild for nwn-data is a good idea - what I am saying is that either this ebuild should be able to handle multiple install variations. It's merely an addition to (not a changing of) your work. Honestly, I am not sure what would be right, so I leave it in the hands of people who know better than I do. It was only a suggestion, after all, and I apologize for not making that clear in the interest of expediency. And as for nwmovies being a hack - it isn't. I wouldn't use it if it was. It's simply an LD_PRELOAD like nwmouse is. And it works perfectly, as far as I can see. The only reason we have to rebuild libSDL is that the game version is built without ALSA (which was not a good idea) and the one Gentoo builds is stripped - which nwmovies cannot handle. I think there is another version in the nwn directory already, but I didn't test to see if it was an update - I preferred just to use the one on-system. The software mixer addition is actually something Gentoo should be doing anyway to prevent a bug from happening - everything else is configuration or a minor patch. No, not a hack - just a bit complicated to install, but it is possible to automate it. That's why I presented it. Nwmovies and nwmouse should really (really!) be part of the client ebuild, not the data ebuild, as it changes things with the client files. Perhaps *that* is another bug? I'll have to leave it for when I get back home, though.
(In reply to comment #35) > Please don't take my comment as a dismissal of your work or an incitement to an > argument. I don't like having that done to me, and I certainly wouldn't do it to > you. I definitely think an idea of a separate ebuild for nwn-data is a good idea > - what I am saying is that either this ebuild should be able to handle multiple > install variations. It's merely an addition to (not a changing of) your work. > Honestly, I am not sure what would be right, so I leave it in the hands of > people who know better than I do. It was only a suggestion, after all, and I > apologize for not making that clear in the interest of expediency. You are apparently completely missing my point. There is a reason why other bugs are filed as a blocker for this one. I will not unmask nwn-data until it works with the numerous media the game was released under. > And as for nwmovies being a hack - it isn't. I wouldn't use it if it was. It's > simply an LD_PRELOAD like nwmouse is. And it works perfectly, as far as I can > see. The only reason we have to rebuild libSDL is that the game version is built > without ALSA (which was not a good idea) and the one Gentoo builds is stripped - > which nwmovies cannot handle. I think there is another version in the nwn > directory already, but I didn't test to see if it was an update - I preferred > just to use the one on-system. The software mixer addition is actually something > Gentoo should be doing anyway to prevent a bug from happening - everything else > is configuration or a minor patch. No, not a hack - just a bit complicated to > install, but it is possible to automate it. That's why I presented it. What you have is a hack. It involves editing files provided by other builds and will not be added as it violates Gentoo policy. Also, it breaks on amd64. There is no need for recompiling libSDL, either. OSS emulation works fine. > Nwmovies and nwmouse should really (really!) be part of the client ebuild, not > the data ebuild, as it changes things with the client files. Perhaps *that* is > another bug? I'll have to leave it for when I get back home, though. I'm not sure if you even took the time to look at the other bugs linked to this one, but nwmouse is one of them. I have looked at nwmovies, and as of this time have no intentions of supporting it due to the lack of functionality for amd64, which also happens to be my development platform. At any rate, this isn't a discussion board, so I'll leave it at that. This is a tracker bug for attaching other bugs and for testing the current ebuilds. Nothing more.
> You are apparently completely missing my point. There is a reason why other > bugs are filed as a blocker for this one. I will not unmask nwn-data until it > works with the numerous media the game was released under. (sigh) I really need to get practice in expressing myself to others, apparently. I'm not asking you to unmask nwn-data. I'm suggesting that since each installation medium is so different, and since BioWare has shown such a propensity for changing how they package things, you might want to classify each version of the data as a separate ebuild and use a virtual for actually installing the game. That's all. I can install (and play) the game just fine, and I'm not too concerned with having an ebuild for it *right now*. > What you have is a hack. It involves editing files provided by other builds and > will not be added as it violates Gentoo policy. Also, it breaks on amd64. > There is no need for recompiling libSDL, either. OSS emulation works fine. Fine. It's a hack. That's why I suggested it as a use flag, rather than as a separate ebuild. The same goes for nwmouse. Even though it works with the current game client, it might *not* work with the next. We need to be able to track these things and work accordingly. And if OSS emulation works fine, then I think I can be forgiven for following the directions given me by the person who released the product. I wouldn't know, though - I haven't tried, and what I have works perfectly. > I'm not sure if you even took the time to look at the other bugs linked to this > one, but nwmouse is one of them. I have looked at nwmovies, and as of this time > have no intentions of supporting it due to the lack of functionality for amd64, > which also happens to be my development platform. At any rate, this isn't a > discussion board, so I'll leave it at that. This is a tracker bug for attaching > other bugs and for testing the current ebuilds. Nothing more. The fact that nwmovies doesn't support amd64 isn't the issue. The whole *game* doesn't really support amd64. I've been crawling around the forums and I have seen people having issues with dual-core amd64 processors in connection with this game. Take that as a warning, by the way. The game-client ebuild should be masked for amd64 right now. And yes, I have read the other bugs. What I had to say I thought (at the time) to be more general than one specific ebuild. I was mistaken on that in some regards, but all I really needed was to be told what points those were, not to have it thrown in my face. What is in *this* post, however, *is* too general. I just want to give fair warning (even if it's unnecessary) that this ebuild structure *will* break if BioWare decides to do something unexpected. I just don't want to see that happen - my goal is to make your work easier. That's all.
> each installation medium is so different, and since BioWare has shown such a > propensity for changing how they package things, you might want to classify > each version of the data as a separate ebuild and use a virtual for actually > installing the game. Before someone misinterprets my comment, let me claify. The other ebuilds under this one deal with *how* to install things, not on what the actual ebuild structure should or should not be. "One file, one ebuild" is the rule, I know, and that's what should happen, but not so it breaks every time BioWare changes its mind on how things install. In the original edition, you had the data, the client, and then you installed the expansion packs as separate cd's. People *will* still do this. It needs support. In the "Gold" edition, you had the original installation the same, but they just packaged the "Shadows of Urentide" expansion with the game. It still installed separately. The "Gold" installation should, therefore, be a virtual. Or not. It matters not. In the "Platinum" edition, BioWare changed its mind and even gave two different installation media. You can't treat this the way you would the "Gold" or original editions, so this calls for a different ebuild structure than the one I am seeing. The "Diamond" edition did the same thing. So: games-rpg/nwn USE: gold, platinum, diamond, sou, hotu, nwmouse, nwmovies With gold, platinum, and diamond being exclusive to each other. With gold and sou being exclusive to each other. With platinum and diamond being exclusive to both sou and hotu. games-rpg/nwn-data Which can install different versions of the game data. If we can't use separate ebuilds, then this will be quite complex. Searching a disc for "markers" without intentional user input is just asking for trouble. But that's the business of a dependant bug. games-rpg/nwn-client-$VERSION Which can install the actual client (last) and optionally install nwmouse and nwmovies. The bug I made for this got marked a dupe of this one. < http://bugs.gentoo.org/show_bug.cgi?id=113530> games-rpg/nwn-cep Which can install the Community Expansion pack and is dependent on games- rpg/nwn. There's an ebuild on this already. This structure should make sure that when BioWare changes its mind again, portage can cope.
OK. I am hating to be rude here, but which part of "this is not a discussion forum" did you not understand. Your additional comments are not contributing to the purpose of this bug. Your information on how to install from the Platinum DVD is appreciated and will be taken into consideration. There's NO NEED to continue posting your opinions on this bug. I don't need nor want them and they are not assisting in resolving this "bug" in any way. I never implied that you asked me to unmask the bug. I was merely stating that this will NOT BE RESOLVED UNTIL IT WORKS on all of the released media. Take that how you want, I don't really care anymore. At no point do I intend on adding a ton of USE flags to this package for the different media types, since we already have support for multiple media sets via the games eclass. PLEASE QUIT PUSHING THAT POINT. It adds a maintenance nightmare much worse than what could be solved through a little bit of initial investment in time. I really don't know how to make it any clearer. I don't care about your opinion on nwmovies, either. I own more than one AMD64 box. I play this game. If it doesn't work on AMD64, then I am definitely not adding such a nasty kludge that I can neither test nor maintain. I'm sorry if this does not fit with what you wish out of this package. As I understand it, you already have it installed the way you want, so it shouldn't matter to you anyway. Again, I'm not bothered by your input, I am just sick of you pushing your ideas repeatedly even after I have said that I'm not interested. Please take the hint. To everyone else, I apologize for this continued bug spam.
I only had one error so far. Dunno if it matters ... <snip> inflating: dialog.tlk unzip: cannot find or open /media/dvdrw//Data_Linux.zip, /media/dvdrw//Data_Linux.zip.zip or /media/dvdrw//Data_Linux.zip.ZIP. * Found CD #2 root at /media/dvdrw/ <snip> btw, 'Found CD #2 strikes me as odd, as I have the platinum CD edition. E.g. I have 4 CD's not one DVD so I am somewhat supprised that it did find the data files belonging to CD2 on CD1 Install/Play CD. Also all other CD's weren't required? So why mention it at the beginning of the ebuild.
OK. The *only* set of CDs that this works with is the separate SoU and HotU CD. It does not pull *ANY* data from NWN. You either have to use USE="nowin" or you have to copy it yourself. If you did anything else, your installation is broken. This is why it tells you exactly which CDs you will need based on USE. I am working to make it support installing NWN (Original/Platinum/Diamond/Gold/Whatever) from the CD/DVD.
Well I did export my USE flags as hou nowin sou. It installed and I put in the Original Key + HoU key. Didn't ask me for SoU. I went on to edit the nwncdkey.ini and add a Key2 value (both 1 and 3 where created with my two inputed keys) but that didn't help in having SoU showing up in the menu. HoU did next to the 'original' however.
Here's the code: if use sou && use hou then echo "You will need the SoU and HoU CDs for this installation." cdrom_get_cds NWNSoUInstallGuide.rtf \ ArcadeInstallNWNXP213f.EXE elif use sou then echo "You will need the SoU CD for this installation." cdrom_get_cds NWNSoUInstallGuide.rtf elif use hou then echo "You will need the HoU CD for this installation." cdrom_get_cds ArcadeInstallNWNXP213f.EXE fi As you can see, it *never* asks for the original CD. You should have put in the SoU CD first, then the HotU CD. Inserting any of the other disks wouldn't work properly.
Tested your ebuilds with SuO and HoU. Everything perfect. Good work. Thanks :-) edmondo@balrog ~ $ emerge info Portage 2.0.53 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r1, 2.6.15-rc5 x86_64) ================================================================= System uname: 2.6.15-rc5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ Gentoo Base System version 1.12.0_pre11 ccache version 2.4 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.91.0.4 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=k8 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo " LDFLAGS="-Wl,--as-needed -Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl eds emboss encode esd exif expat fam ffmpeg foomaticdb fortran gif glut gmp gnome gpm gstreamer gtk gtk2 hal idn imagemagick imlib ipv6 ithreads jpeg kde lcms linuxthreads-tls lm_sensors lua lzw lzw-tiff mad mng mp3 mpeg ncurses nls nowin nptl nptlonly ogg openal opengl pam pcre pda pdflib perl png python qt quicktime readline samba sdl spell ssl tcpd theora threads tiff truetype truetype-fonts type1-fonts udev usb userlocales vorbis xine xml2 xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS, PORTDIR_OVERLAY
Works fine for me on the UK Deluxe Edition (3 CDs NWN, 1 CD SoU, 1 CD HotU; 3 CD Keys). I had the v1.66 single ebuild with just NWN and then updated to split +SoU +HotU. I can't believe they made me type in 3 CD keys... emerge info Portage 2.0.51.22-r3 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-gentoo-r4 x86_64)
I tried to follow the instructions of Chris Gianelloni. After emerge nwn, I get this: Calculating dependencies... done! >>> Emerging (1 of 2) games-rpg/nwn-data-1.29 to / >>> Downloading http://xfer06.fileplanet.com/%5E389272944/082003/nwgerman129.tar.gz --17:25:32-- http://xfer06.fileplanet.com/%5E389272944/082003/nwgerman129.tar.gz => `/usr/portage/distfiles/nwgerman129.tar.gz' Resolving xfer06.fileplanet.com... 64.79.161.136 Connecting to xfer06.fileplanet.com|64.79.161.136|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 17:25:33 ERROR 403: Forbidden. !!! Couldn't download nwgerman129.tar.gz. Aborting. this is my /etc/make.conf CFLAGS="-O2 -pipe -march=k8" MAKEOPTS="-j2" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" USE="nptl nptlonly 3dfx 3dnow X aac acpi aim alsa apache apache2 bmp bzip2 cdparanoia cdr dvd dvdr dvdread emul-linux-x86 fdftk ftp gd -gnome -gtk icq imap java javascript kde qt mono mozilla mp3 msn mysql mysqli nvidia oggvorbis oscar pdf php perl postgres samba soap svg tidy unicode win32codecs xml" LINGUAS="de" ACCEPT_KEYWORDS="~amd64" INPUT_DEVICES="keyboard mouse" VIDEO_CARDS="nv nvidia vesa"
(In reply to comment #46) > >>> Emerging (1 of 2) games-rpg/nwn-data-1.29 to / > >>> Downloading http://xfer06.fileplanet.com/%5E389272944/082003/nwgerman129.tar.gz I'm having this problem as well actually. My workaround was changing LINGUAS in make.conf from "en_uk de" to "en_uk". I tried getting the file for maybe an hour or so, but failed. If I remember correctly I found a page that seemed to have it, but it wouldn't work in my amd64 system with Firefox or Opera. This happened after remerged my toolchain twice, then system twice, and was in the process of remerging world as I updated GCC from 3.4.4-r1 to 3.4.6. I think the existing merge of NWN was done with LINGUAS commented out, although that was for another reason. emerge info *** Deprecated use of action 'info', use '--info' instead Portage 2.1_pre7-r5 (default-linux/amd64/2005.1, gcc-3.4.6, glibc-2.3.6-r3, 2.6.15-gentoo-r7 x86_64) ================================================================= System uname: 2.6.15-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://mirrors.blueyonder.co.uk/mirrors/gentoo/ ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" LINGUAS="en_GB en" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac aalib acpi alsa atm audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr crypt dba dga directfb divx4linux dri dvd dvdr dvdread emboss emul-linux-x86 exif expat fam ffmpeg firefox font-server foomaticdb fortran gd gdbm gif gpm gstreamer gtk gtk2 gtkhtml howl imap imlib isdnlog java javascript jikes jpeg kde lzw lzw-tiff mad memlimit mhash mng motif mozilla mp3 mpeg ncurses nfs nls nptl nsplugin nvidia offensive ogg opengl openssl pam pcre pdflib perl php plotutils png pppd python qt quicktime readline samba sdl sharedext sharedmem slang spell ssl svg symlink tcltk tcpd tiff truetype truetype-fonts type1-fonts unicode usb vorbis xine xml xml2 xmms xosd xpm xv xvid zlib elibc_glibc kernel_linux linguas_en_GB linguas_en userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS
I have downoaded nwgerman129.tar.gz now from fileplanet.com and moved the file into /usr/portage/distfiles. After that, the emerge run without problems.
OK, now it is installed, and I have fixed my Nvidia-Problem (off-topic), and I try to run nwn. First, the monitor gets dark for 2 seconds, then I get the error: Fatal signal: Segmentation Fault (SDL Parachute Deployed) Any Ideas?
Looks just like bug #129922
Problem with: USE="nowin" emerge nwn-data None of the three URL's searched by the ebuild have the nwresources129.tar.gz file. I had to download it manually from bioware int /usr/portage/distfiles. Other than that, the install went fine.
The 1.67-r1 ebuild (ugrading from 1.66-r1), with the nowin, hou, sou use flags, works perfect here (using the original game and seperate expansion pack CDs).
OK. So I've thought about this and have decided that there really is no point in keeping this stuff masked forever. I know that I haven't quite had the time to support all of the 13 million ways to install NWN over the various media. I also know that it is unlikely that I'll be finding the time to complete this within a decent timeframe. Because of this, I'm removing the dependencies on the other media sets, and am marking this is RESOLVED-FIXED. I'm also unmasking these ebuilds, as they really are much better than the monolithic ebuild. It allows me to only have to bump a single ebuild set, and it also allows for easier addition of new media sets in the future. All in all, I think that everyone will be much happier this way. I only wish I'd done this sooner.
