Enables playing Duke Nukem 3D on GNU/Linux systems, given you own the original game. This new ebuild isn't final, but it has most of things needed to work. I put it here waiting for a tester / maintainer. Have fun.
Created attachment 114366 [details] eduke32-1.4.0_beta2.ebuild Please note that the license field hasn't been filled in!
Created attachment 114467 [details] eduke32-1.4.0_beta2.ebuild Adds hi-res textures. Works with demo data. Doesn't have any sound, though.
Created attachment 114472 [details] eduke32-1.4.0_beta2.ebuild Added duke.rts, to remove warning in log file.
Created attachment 117170 [details] eduke32-1.4.0_beta2.ebuild I patched the last ebuild to work with lower-case and mixed-case filenames. Isn't there any better solution then putting the files into ${FILESDIR}?
eduke32 is sensitive to -fweb in CFLAGS with GCC 4.1.2. With it specified it segfaults after selecting New Game from the main menu.
The new developmentversions in http://wiki.eduke32.com/stuff/ have some nice improvements.
I updated this ebuild for the latest version of eduke32, currently 20100625 (build 1661). I actually pretty much completely rewrote the original ebuild, for a couple reasons: 1. The source code has improved quite a bit in the last 3 years, so all of the unpack and compile stuff in the previous ebuild no longer applied 2. I really didn't understand how the game data installation stuff was supposed to work. It looked like it was pulling everything from the ebuild's files directory, which didn't make any sense to me. So, I dropped all of that with the assumption that the data files can be installed with duke3d-data (more on that below). 3. The high resolution textures are optional now since they're so large and the game can be played just fine without them. I also added (optional) music files as well, which is helpfule since the original MIDI output doesn't seem to work correctly under Linux. As I said above, game data should now be installed with duke3d-data. I had to modify this ebuild as well for that to work, so I'm posting the updated version here. Changes: 1. Support both duke3d or eduke32 2. Support Atomic Edition CD-ROM 3. Support amd64 Ebuilds both work great for me. I'd love to hear any feedback, especially in regards to getting this added to portage since the "official" duke3d builds are old, incomplete, and don't support amd64.
Created attachment 236581 [details] games-fps/eduke32-20100625.ebuild
Created attachment 236583 [details] games-fps/duke3d-data-1.0-r1.ebuild
Created attachment 236771 [details] games-fps/eduke32-20100625.ebuild Couple updates: 1. Original (midi) music will work, but requires timidity and appropriate sdl-mixer support. If the 'music' USE flag (for the add-on music) is disabled, sdl-mixer[timidity] is now required. If 'music' is enabled, timidity is not required and thus not forced. 2. Removed nasm dep - not required to build.
Created attachment 236783 [details] games-fps/eduke32-20100625.ebuild One more tiny update: 1. Changed 'hires' USE flag to 'textures' for consistency with other similar ebuilds.
Created attachment 245954 [details] games-fps/duke3d-data-1.0-r1.ebuild I'm not happy with the data ebuild. The conditional makes the behaviour a little unpredictable. What if you have both games installed? Symlinks are the answer here. I thought about symlinking duke3d to eduke32 but that will create problems with the current ebuilds and existing installations. Instead I have symlinked the required files themselves. Note that the *.con files are NOT required by eduke32. If I remember correctly, these files are actually included within duke3d.grp and were only installed separately in case you wanted to make modifications to them. This simplifies things because the old duke3d engine DOES require the files and probably only works with the Atomic Edition versions of them. They are included with that engine in case you only have the original edition like I do so there is no point installing them from the CD. There is what appears to be a typo in the previous (and in-tree) ebuilds where dn3dinst is prefixed with dvd/. This doesn't make any sense, given that the prefix is missing below. Apart from anything, DVDs had barely come into existence when this game was released. ;) There is no need to check whether cdrom_get_cds worked. The command does its own checking. We should also be specific about which files we are installing instead of using wildcards. We don't know for sure which files are present and which are not. The eduke32 ebuild seems okay but I tried bumping it to 20100831 and found I had to define ARCH= before compiling. This is because the Makefile now uses ARCH for arch-specific CFLAGS while Portage defines this as just amd64 or whatever. They probably should have used a less ambiguous variable name. I have filed a bug report about this here. http://sourceforge.net/tracker/?func=detail&aid=3059356&group_id=126745&atid=706724 A note to R600+ users running xf86-video-ati, I had to disable the hi-res textures and polymer mode before things started to look right.
Created attachment 245999 [details] games-fps/eduke32-20100831.ebuild Given this some more thought and here's a better ebuild for eduke32. Binaries really shouldn't go in /usr/share if you can help if so I've installed them to /usr/games/bin but given them a .bin extension. The wrapper doesn't actually need to change directory and rather than do that nasty sed stuff, you can provide the extra arguments when calling make_wrapper. They're now passed to mapster32 as well. Not sure if it can use the hi-res stuff but doesn't hurt. The editor help file is now installed. I can't remember the key bindings after 12 years. ;) Finally, the binaries are no longer pre-stripped by setting STRIP=touch.
What about Polymer HRP? Also, will be cool to have ability to install some addons (like xxx pack ^_^) in centralized and automatic way. Maybe, we need some additional ebuild or other mechanism for it.
Hello, can be this ebuild included?
Cool that there's an ebuild already :) I am gonna try it within the next couple of days if I get time. if it works ok I can stick it into my dev overlay for further testing if you want to. .. also depends on when I get my copy of Duke Nukem Forever ^^
I'm attaching an updated ebuild for version 20120225. This also bumps support for the High Resolution Pack up to 5.1. Probably the biggest change is that the Polymer renderer is now both default for eduke32 and very strongly recommended for the HRP, so I took out the USE flag. If, for some reason, polymer can't be used, you can disable opengl altogether, which will have the net effect of also disabling polymer. Or, you're welcome to update the ebuild to add support for the option again. :-) I also added a few new USE options, so stuff like the GTK GUI is now option. Nothing too exciting, but you may want to review the new options when upgrading. I also included James' improvements from his last update (sorry James, somehow missed your update and started working from my own old ebuild; added all of your changes after the fact). I did a fair amount of testing and it seems to work reasonably well, but: * I only tested with opengl+polymer * I did not test editor, vpx, or music pack support * I only did very limited GUI testing, since I use launcher scripts Lastly, gameplay seems to have periodic stuttering that I don't remember in the old version. Not sure if it's something wrong with my system, the new eduke32 version, the switch to polymer (I was using polymost previous to this version)), or maybe something with the new HRP files. Would be curious if anyone notices this as well.
Created attachment 303303 [details] games-fps/eduke32-20120225.ebuild
I spent way, way too much time working on this the last few days, but I have a pretty massive update to share with lots of new features and ebuilds. First up, eduke33. Major changes: * Support for Duke It Out in D.C., Duke Caribbean: Life's a Beach, and Duke: Nuclear Winter expansion packs (see additional information in separate comments below) ** USE flags for each expansion do two things: PDEPEND on that expansion, and add pre-configured shortcuts for the expansion * Support for XXX and XXX-lite texture packs * Data files are now expected to be installed in /usr/share/games/duke3d (see comments in duke3d-data post below) Minor changes: * Support for build engine utilities (a couple of which are required for the expansion packs) * Documentation from texture packs installed * Fixed shortcuts for editor - overlooked some changes in my last ebuild * Fixed issue with eduke3d always writing a log file to $PWD. It's now written to /tmp * Additional useful information output in postinstall By the way, the stuttering I mentioned in my last comment doesn't really seem to be an issue. I think it was just an artifact of repeatedly loading quick games for testing. When playing normally, I haven't noticed the problem.
Created attachment 303657 [details] games-fps/eduke32-20120225.ebuild see comments above
Created attachment 303659 [details] games-fps/duke3d-data-1.0-r2.ebuild This, again, takes advantage many of James' previous improvements, with one major change: * Data files are now installed into ${GAMES_DATADIR}/duke3d rather than ${GAMES_DATADIR}/eduke32 I agree that the previous one wasn't well done, but rather than doing symlinks I thought it'd be better to always have a common directory for Duke Nukem 3D data files. Aside from being more convenient and more predictable, it also just makes more sense to me: game data should be installed in a directory specific to that game, not to a particular engine. This also puts it more inline with stuff like quake2, doom3, etc., where the game data is always installed in a single directory regardless of the engine used. It did require a two-line change to the eduke32 source, but I felt the benefits outweighed the cons. Also, please note that I used this same convention for all of the expansion pack ebuilds that are to follow.
Created attachment 303661 [details] app-arch/unpackssi-20030612.ebuild This utility is necessary for extracting the game data files from Duke It Out in D.C. and Duke Caribbean. I debated whether it should be made an separate ebuild since it's likely to only *ever* be used for installing those two expansion packs, but since it's technically a standalone utility that needs to be used by more than one ebuild, I thought it better to keep it separate.
Created attachment 303663 [details] games-fps/duke3d-dukedc-1.0.ebuild Rolling right along, here's the first, and simplest expansion pack. This is the simplest of the bunch, as the texture pack is prepackaged for it. The only catch is that eduke32 must be installed before this is installed because it requires the use of a utility that's installed along with eduke32, hence the PDEPEND comment in my last eduke32 post. That lets me both have eduke32 depend on this so it can setup the shortcut, as well as have this depend on eduke32 for the necessary binary. Portage is pretty awesome. :-) One other note: This only supports installation from CD in order to match the other two ebuilds. Whereas this one is pretty straightforward and it wouldn't be that difficult to add support for copying from an existing install, the shear amount of work I had to do with the other two in order to allow them to work both with and without the textures made it pretty much impossible there. I originally did have existing install support included in the dukedc ebuild, but I took it out to match the others. If anyone is willing to help out with this AND has an existing install of duke3d plus all three expansions, I'm certainly willing to revisit this, but I don't think that's likely to happen...
Created attachment 303665 [details] games-fps/duke3d-caribbean-1.0.ebuild Second expansion: Duke Caribbean: Life's a Beach. This is much more tricky for a couple reasons: * There are no pre-packaged texture packs, so it needs to be pulled down via SVN (hence the subversion dependency) * The hires textures are mixed up with a 'plus' version of the game, which features various bug fixes, map tweaks, and other enhancements. In order to get the textures, you must also install the plus version. This isn't a bad thing, just complicated. If you look at my ebuild and wonder "WTF was this guy thinking?", understand it took me many, many hours to figure out how to make this work just right and that all those odd things are in there for a reason. If you're interested in working with it or making improvements and have any questions, please, by all means, ask away. Few notes: * This can only be installed from CD, due to the aforementioned complications * It can be installed and played with our without the additional textures/plus features, but because I the eduke32 shortcut needs to be changed depending on whether textures are used, I had to force a [textures=] depend in eduke32. So, if you want textures in eduke32, you'll also need to install them with this (and the other expansion packs). * In order to support both the standard and texture/plus versions, I had to get a little creative when installing the CON files. I had to name the official ones differently so that they don't conflict with plus, as well as update the main CON file to recognize the new names of the others. Not pretty, but it works. * As noted previously, the plus version includes fixes/tweaks for the maps, which are distributed as binary patch files. The ebuild supports this, but it adds a dependency on bsdiff. Think that should cover it.
Created attachment 303667 [details] games-fps/duke3d-nwinter-1.0.ebuild Last expansion - Duke: Nuclear Winter. For the most part, the same comments from Duke Caribbean apply here as well. There are some minor difference in the ebuilds because of how the games were originally packaged on CD, but the end result is the same. That covers it for my updates tonight. Hope at least some of you find this useful. :-) Feedback and/or questions welcome.
It can't find the hi-res zipfile, crashing the ebuild. I don't even use the hi-res, which makes this bug terribly annoying. It works if i istall it manually, anyway
What zip file are you referring to? I just tried downloading all of the texture packs, and they seem to work fine to me. As for it being annoying because you don't use the feature, that's part of the issue with using out-of-tree ebuilds. Checksums for all referenced files must be checked at install time, and while in-tree packages provide these checksum manifests for you, with out-of-tree software you must build it yourself. Thus, the ebuild utility will pull down all references packages so it can create the checksum for all of them. If you don't need a particular feature, comment that out in the ebuild and remove the corrosponding entry from SRC_URI, then re-run ebuild ... digest. That should force it to skip download whatever package you don't plan on using.
Created attachment 323826 [details] games-fps/duke3d-data-1.0-r2.ebuild minor duke3d-data ebuild update: cdrom eclass must now be explicitly included
Created attachment 324260 [details] games-fps/duke3d-caribbean-1.0.ebuild minor duke3d-caribbean ebuild update: cdrom eclass must now be explicitly included
Created attachment 324262 [details] games-fps/duke3d-dukedc-1.0.ebuild minor duke3d-dukedc ebuild update: cdrom eclass must now be explicitly included
Created attachment 324264 [details] games-fps/duke3d-nwinter-1.0.ebuild minor duke3d-nwinter ebuild update: cdrom eclass must now be explicitly included
Created attachment 336290 [details] app-arch/unpackssi-20030612.ebuild Updated ebuild for unpackssi. By default it would crash on my system after rebuilding it with GCC 4.6. With Hu's help in this thread: https://forums.gentoo.org/viewtopic-t-947588-highlight-unpackssi.html We tracked it down to being an issue with 64-bit compatibility. The updated ebuild patches the code for proper 64-bit support.
One of the issues I think we need to address with eduke32 is that the various addon packs such as HRP and so on do not have version numbers in the archive file names. For example, version 5.2 of the HRP is out, but the filename is duke3d_hrp.zip just like all the previous versions. Once eduke32 is in mainline Portage (hopefully it will be eventually), the files will be on the Gentoo mirrors and we could rename them as needed, but is there anything we can do before that? Until that issue is resolved, the file integrity check will fail whenever a new version comes out and Portage expects the value of a previous version when it checks MD5 and so on. I emailed upstream yesterday asking for version numbers in the archive file names, but if they are unwilling or unable to do so, we'll need to find a solution on our end.
That is easily worked around using the SRC_URI -> feature.
+*eduke32-20130201.3453 (02 Feb 2013) + + 02 Feb 2013; Julian Ospald <hasufell@gentoo.org> + +eduke32-20130201.3453.ebuild, +files/eduke32-20130201.3453-QA.patch, + +metadata.xml: + initial import wrt #172183
hasufell, Nice to see this added to the tree, but why did you remove all of the features from the ebuild? The one in the tree is much less capable than what's provided here, as it doesn't support any of the extra community content (high resolution pack, etc.) or expansion packs. That stuff's kind of important if you want the complete experience. I don't think this bug should be considered 'fixed' as-is.
what features? and yes, there is a TODO in my ebuild about "extras". Paddymac had prepared such an ebuild but I didn't see him in the last days.
(In reply to comment #37) > what features? All of them. Support for: * high resolution textures * music pack (for people that have trouble with, or don't want to use midi) * xxx/xxx-lite textures * Duke it out in D.C. expansion * Duke Caribbean expansion * Nuclear Winter expansion Your ebuild doesn't include, or even mention, any of this. Yes, I saw some todo comments at the top of the ebuild, but they don't relate to anything in the existing ebuild. I have no idea what lunatic is, 'extras' is quite vague, and clang has never been reported as an issue, at least not in this thread. Did you source your ebuild from somewhere else? If so, you should really try reviewing the one in this bug, as it's way more complete. I'm sure it could use an update (convert to EAPI=5, that sort of thing), but it's pretty solid and much more capable than the one now in-tree. Support for all of the expansion packs in particular is a significant loss. Do appreciate you efforts, don't get me wrong, just don't understand why you went that route here.
(In reply to comment #38) > (In reply to comment #37) > > what features? > > All of them. Support for: > * high resolution textures > * music pack (for people that have trouble with, or don't want to use midi) > * xxx/xxx-lite textures > * Duke it out in D.C. expansion > * Duke Caribbean expansion > * Nuclear Winter expansion Those require additional ebuilds and are on my TODO list. > > Your ebuild doesn't include, or even mention, any of this. Yes, I saw some > todo comments at the top of the ebuild, but they don't relate to anything in > the existing ebuild. I have no idea what lunatic is, 'extras' is quite > vague, and clang has never been reported as an issue, at least not in this > thread. Lunatic seems to be an interpreter and WIP. Actually it does compile with clang. The failure must have been a quirk while messing with those Makefiles. > > Did you source your ebuild from somewhere else? If so, you should really > try reviewing the one in this bug, as it's way more complete. from a quick look it has tons of bugs I already fixed in the new one. Rebase your ebuild on the one in the tree. But I do not intend to add tons of useflags that could be outsourced to new ebuilds. > I'm sure it > could use an update (convert to EAPI=5, that sort of thing), but it's pretty > solid and much more capable than the one now in-tree. It is not more solid, it does not have any QA (see the QA patch). It is missing dependencies (or missing slot such as for libpng), has wrong license, broken useflag logic (gtk+ is _not_ optional), it does not use games.eclass properly (such as ignoring games_pkg_setup which may result in missing games user/group), it does not fix the log directory properly and a few other things I do not like. As said, please rebase your ebuilds on top of the current tree ebuild. That makes it easier for me to support extras. I am not part of the eduke32 community, so you guys might know better about that texture/mod etc stuff. > Support for all of > the expansion packs in particular is a significant loss. > TODO > Do appreciate you efforts, don't get me wrong, just don't understand why you > went that route here. Because I want high quality ebuilds and did not have time yet to work on the extensions.
(In reply to comment #39) > from a quick look it has tons of bugs I already fixed in the new one. Rebase > your ebuild on the one in the tree. But I do not intend to add tons of > useflags that could be outsourced to new ebuilds. will be happy to. I'll update the expansion pack ebuilds to the same style as well. Not sure what you mean by the "outsourced to new ebuilds" comment, though. Can you elaborate? The obvious USE flags I'd add back are: caribbean, dukedc, nwinter - automatically pulls in expansion packs, which is a fairly standard convenience editor and gtk - last version I built (20120225) these were both optional, so if that's still true I'd rather not force it if it's not really needed (based on your later comments, that may no longer be true of gtk) textures and music - this seems fairly standard as well, but perhaps you'd prefer something like 'extras'? > It is not more solid <snip> I never claimed that it was *more* solid, just that it *is* solid (as in it works perfectly fine) and is more capable. As I already mentioned, I know it could use a good cleanup, but given no developer had actually expressed any interest in adding this to the tree until your commit yesterday, it hasn't been that high on my priority list. I've simply kept updating it as necessary to make it work on my system whenever I do a rebuild. Given your sudden interest, though, I'll be more than happy to tighten it up, and will use your version as the new base. I had a lot of fun playing through this again last year, and would love to see it in the tree, along with its expansions. Probably won't get a chance to work on it today, but will do so one night later this week. On that note - you still have this flagged as fixed. Would you like to re-open this while I work on the updates, or would you prefer that I file a new bug about it? Personally I think re-opening this one since it already has the full history makes sense, but I don't mind filing a new report if that's your preference. > Because I want high quality ebuilds and did not have time yet to work on the > extensions. Which is a great goal, of course, but in this case the expansions and support for all of the additional features are already done. That's why I say I don't understand. If you want to add this but don't have time to tackle and update everything at once, that's fine - just let me know, and I'll be quite happy to update them for you. I think it makes far more sense to take advantage of the work already out there, and people obviously willing to commit some time to this, than starting over from scratch. There are dozens of other bugs in bugzilla relating to games that I've updated or improved in some way, and I'd love to see all of those folded back into the tree. But, I'm sure my coding style is different from yours, and like this one, I'm sure some of them are dated by now and need to be updated. If you interested in picking any of those up as well, please, just let me know in advance and I'll do as much of the cleanup as I can for you.
(In reply to comment #40) > (In reply to comment #39) > > from a quick look it has tons of bugs I already fixed in the new one. Rebase > > your ebuild on the one in the tree. But I do not intend to add tons of > > useflags that could be outsourced to new ebuilds. > > caribbean, dukedc, nwinter - automatically pulls in expansion packs, which > is a fairly standard convenience In fact, that is invalid. Even cdinstall and demo useflags are invalid, but I make an exception here. Maybe it's even better to remove them and just point to the ebuilds in pkg_postinst. Optional dependencies must not be behind a useflag unless they change a) what gets installed by _this_ ebuild or b) change anything during build time. They do not. There are several suggestions to fix this situation, so we don't have useless rebuilds of packages, but none is implemented yet. > > editor and gtk - last version I built (20120225) these were both optional, > so if that's still true I'd rather not force it if it's not really needed > (based on your later comments, that may no longer be true of gtk) No, gtk is just dlopened (also for eduke32) when you switch off your gtk useflag. > > textures and music - this seems fairly standard as well, but perhaps you'd > prefer something like 'extras'? I don't know of such a standard. A meta ebuild would even be worth to consider. > > Because I want high quality ebuilds and did not have time yet to work on the > > extensions. > > Which is a great goal, of course, but in this case the expansions and > support for all of the additional features are already done. That's why I > say I don't understand. If you want to add this but don't have time to > tackle and update everything at once, that's fine - just let me know, and > I'll be quite happy to update them for you. I think it makes far more sense > to take advantage of the work already out there, and people obviously > willing to commit some time to this, than starting over from scratch. In my experience it takes more time to clean up other peoples ebuilds instead of starting from scratch. That is partly because you don't check everything yourself and assume that things were done on purpose. That's often wrong. Then you end up reverse-fixing things. Anyway, I had PaddyMacs ebuild as a draft. He joined #gentoo-sunrise and asked for review. That's how things get into the tree (or at least into sunrise) ;)
Wow! I came here to nab some of the ebuilds here and take a look at them. I didn't expect all this activity. In my spare time over the past few days, I rewrote the base eduke32 ebuild (it's currently on my overlay). Hasufell was a big help with QA. The layout I personally had in mind was to just have the base eduke32 ebuild only install the eduke32 game and split out the addons into individual ebuilds. I figured this would simplify things a lot and make ebuild maintenance easier instead of having absolutely everything in one ebuild. The design I had envisioned was to have eduke32.ebuild have an "extras" use flag which pointed to a metapackage eduke32-extras.ebuild. This metapackage would in turn pull in any of the various addons according to use flags. This at least made sense to me (of course the way I see things isn't always the way everyone else sees them). I've essentially been using my own overlay as a sort of testing ground for things to submit here, and as such I realize that some features may get canned instead of going into mainline tree. Anyway, a few things about the ebuild I wrote (which is, with a few changes, what is now in tree): 1) I attempted to redirect the log files to /var/log/games. This is currently not working as expected (I tried to emulate the method used by games-server/tetrix). 2) Eduke32 still uses some bundled libraries: enet, jaudiolib, and jmact. enet is already in the portage tree; the other two are not. So if we are to ensure that only external libraries are used instead of bundled libs, we need to get the jaudiolib and jmact libs in tree in addition to patching the Makefile to use the external libs. Unless they are customized versions for eduke32, I think they are the same as the jfaudiolib and jfmact libs at https://github.com/jonof (I have been working on writing ebuilds for these two libs in my spare time). 3) I haven't tried the ebuild in tree, but on my overlay I have a patch which ensures that cflags are respected (I finished it after my conversation with Hasufell). I can post it here if need be. 4) There's probably some other things that I don't recall at the moment.
(In reply to comment #42) > Wow! I came here to nab some of the ebuilds here and take a look at them. I > didn't expect all this activity. In my spare time over the past few days, I > rewrote the base eduke32 ebuild (it's currently on my overlay). Hasufell was > a big help with QA. The layout I personally had in mind was to just have the > base eduke32 ebuild only install the eduke32 game and split out the addons > into individual ebuilds. I figured this would simplify things a lot and make > ebuild maintenance easier instead of having absolutely everything in one > ebuild. The design I had envisioned was to have eduke32.ebuild have an > "extras" use flag which pointed to a metapackage eduke32-extras.ebuild. This > metapackage would in turn pull in any of the various addons according to use > flags. This at least made sense to me (of course the way I see things isn't > always the way everyone else sees them). I've essentially been using my own > overlay as a sort of testing ground for things to submit here, and as such I > realize that some features may get canned instead of going into mainline > tree. I suggest you work together with Jared B. to get the maximum out of it. I'm not familiar with all the addons/extensions, so I'd just review those things. > > Anyway, a few things about the ebuild I wrote (which is, with a few changes, > what is now in tree): > > 1) I attempted to redirect the log files to /var/log/games. This is > currently not working as expected (I tried to emulate the method used by > games-server/tetrix). the in-tree ebuild fixes that, the log files had simply incorrect permissions. > > 2) Eduke32 still uses some bundled libraries: enet, jaudiolib, and jmact. > enet is already in the portage tree; the other two are not. So if we are to > ensure that only external libraries are used instead of bundled libs, we > need to get the jaudiolib and jmact libs in tree in addition to patching the > Makefile to use the external libs. Unless they are customized versions for > eduke32, I think they are the same as the jfaudiolib and jfmact libs at > https://github.com/jonof (I have been working on writing ebuilds for these > two libs in my spare time). Ok, this should be a TODO as well. However, we need to check with upstream first if the bundled libraries are modified. If that is the case, then they cannot be unbundled. > > 3) I haven't tried the ebuild in tree, but on my overlay I have a patch > which ensures that cflags are respected (I finished it after my conversation > with Hasufell). I can post it here if need be. That's already fixed. > > 4) There's probably some other things that I don't recall at the moment. Feel free to ping me on irc or join #gentoo-games
@Jared B. Thanks for your initial work on the ebuild! I also used it a long time and i never got errors... I also had the opinion that the ebuild like it was, was perfectly. yes maybe not totally perfectly but it supported all what was needed for the best experience. And in every way better maintained as the one in portage or in other overlays which was outdated... i was shoked as there was a portage update and suprisly the portage ebuild failed to emerge and i had to give your ebuild in my local overlay more pirority and also using it now. all the time i have only changed the numbers for updating it. i also would be happy if jareds work and support for HRP and extras would be integrated. i have tested it like the begin and it was proper and stable in every day use. but maybe it would be really better to outsource the packages from hrp in seperate ebuilds like other games do it. but the ebuild eduke32 itself should have all or the most important features use flags anymore. best regards chris
And eventually you jared should open your own overlay for all of your games maybe. than you dont have to hassle about that they need years to go to the tree or maybe never and all fans of your game ebuilds would have a nice overview about all of your ebuilds/games.
(In reply to comment #44) > i was shoked as there was a portage update and suprisly the portage ebuild > failed to emerge thanks for not reporting a bug anyway, I figured out the problem, you are probably using clang and tools useflag
+ 09 Feb 2013; Julian Ospald <hasufell@gentoo.org> + files/eduke32-20130201.3453-QA.patch: + fix build on clang please try again
any progress here? I expected a load of patches after your rants, but nothing happened.
(In reply to comment #48) > any progress here? > > I expected a load of patches after your rants, but nothing happened. Some, but nothing significant enough to post yet. I've been busy with other stuff, and also not terribly motivated to rewrite a bunch of ebuilds I and several others already spent almost six years tweaking and refining, the ones you completely ignored when you closed this bug as resolved without even bothering to review it.
(In reply to comment #49) > (In reply to comment #48) > > any progress here? > > > > I expected a load of patches after your rants, but nothing happened. > > Some, but nothing significant enough to post yet. I've been busy with other > stuff, and also not terribly motivated to rewrite a bunch of ebuilds I and > several others already spent almost six years tweaking and refining, the > ones you completely ignored when you closed this bug as resolved without > even bothering to review it. commenting on attachment 303657 [details]: - header is wrong - ebuild uses old EAPI, use latest EAPI whenever possible - "as-is" license is deprecated and invalid, probably missing license for those extensions too - stable keywords - missing dependencies: media-libs/libogg media-libs/flac sys-libs/zlib virtual/glu - media-libs/libpng and x11-libs/gtk+ are missing a slot which can lead to build failure - missing useflags for dependency media-libs/libsdl: X joystick opengl video - you overwrite games_pkg_setup which can lead to a broken installation and the user being unable to access the game - the useflag validation logic in pkg_setup is obsolete, use REQUIRED_USE instead - why do you use subshells in pkg_setup? - wrong location for logdir in the second sed in src_prepare - "cd" is missing a "|| die" in src_compile - RELEASE=0 will mess up cflags for debug support - NETCODE and NOASM build options are not used - a lot of tools are missing in src_install if "utils" useflag is enabled - src_install is not the place for unpacking - unzip is missing "|| die" everywhere - no icons installed - editor is _always_ built, but not always installed. That does not make much sense. Either fix the build system to exclude the mapster32 build or have a good reason for that behavior e.g. due to additional dependencies which is not the case here - build-log is not verbose - build does not respect CC, CXX, AR, AS, RANLIB, PKG_CONFIG, CFLAGS, CXXFLAGS, LDFLAGS and adds other unwanted flags - it automagically enables LTO which is bad - it uses dlopen on gtk by default which is not preferred, because we are unable to find broken linkage via revdep-rebuild then; set LINKED_GTK=1
commenting on attachment 324260 [details] and 324264: - header is wrong - use latest EAPI - cdrom.eclass already sets PROPERTIES="interactive" - license "as-is" is deprecated - stable keywords: this is a live ebuild, because it fetches from a repository and must not have any keywords (even if that is optional). Create a snapshot or outsource that part into a new ebuild - subversion.eclass already sets dev-vcs/subversion as build-time dep - "zip," "mv", "cd", "mkdir", "kextract", "rm" are missing a "|| die" - use "einfo" instead of that echo in src_prepare - doins takes more than one argument - you overwrite games_pkg_postinst commenting on attachment 324262 [details]: - header is wrong - use latest EAPI - stable keywords - cdrom.eclass already sets PROPERTIES="interactive" - license "as-is" is deprecated - eutils.eclass is unused here - seems that app-arch/unzip is missing from DEPEND - kgroup and unzip are missing a "|| die" - you overwrite games_pkg_postinst commenting on attachment 336290 [details]: - header is wrong - use latest EAPI - stable keywords - provide a real Makefile with install rules, but since the project seems almost dead I guess that won't matter much - provide a patch for the unpackssi.c as well, sed is more for conditional things and injecting ebuild variables somewhere - you do not inherit toolchain-funcs - eutils is unused
(In reply to comment #50) > commenting on attachment 303657 [details]: Thanks for the constructive comments. Much of this doesn't really apply here anymore since you asked me to rebase my ebuild on the phone you submitted to the tree (which I'm in the process of doing now), but it's good to know for future reference. I'm curious in particular about the following issues you raised. Can you please explain the following a bit more, so I better understand how/why it should be done going forward? > - ebuild uses old EAPI, use latest EAPI whenever possible Is this actually a stated policy somewhere? I've looked for this a few times before and couldn't find it addressed in the official documentation (though I certainly could have missed it). I'd normally take the approach of using an older EAPI unless the ebuild requires (or at lease could benefit from) newer features so that it's available to the most people possible, rather than only those with the most recent portage updates. > - missing dependencies: media-libs/libogg media-libs/flac sys-libs/zlib > virtual/glu This is tangentially related to another item I've never found an official answer to. If package A depends on both packages B and C, but package B also depends on C, then what's "more" correct? * Add just a dependency on package B since it'll automatically pull in package C, or * Add a dependency on both packages B and C, even through C is redundant in this case I've seen different developers take different approaches, and I've done both myself. Is there an official policy on this? > - you overwrite games_pkg_setup which can lead to a broken installation and > the user being unable to access the game I take it you're referring to the use of pkg_setup()? I didn't realize that also overwrote games_pkg_setup(). While this custom function is no longer needed here thanks to the availability of REQUIRED_USE, I'm curious about how this should be handled in the future. What's the correct way to use pkg_setup() inside a games ebuild without overwriting games_pkg_setup and causing the unintended consequences you mentioned? > - no icons installed That's only because no icons exist(ed) in the source. I see you've added a separate zip file for the icons for your ebuild. I think that's a great idea. Where did you get the icons? I'd love to include icons for the expansion packs as well. > - editor is _always_ built, but not always installed. That does not make > much sense. Either fix the build system to exclude the mapster32 build or > have a good reason for that behavior e.g. due to additional dependencies > which is not the case here My reason is that I have no reason or desire for the editor to be installed, so I'd rather it not be needlessly cluttering my menu and games_bindir. Is that not reason enough? I don't see why it matters whether it's always built or not. Yes, it'd be ideal if it was possible to easily exclude it from the build process, but modifying the build scripts when it can simply not be installed after the fact seems needlessly complicated.
Created attachment 342454 [details] hrp_art_license.txt License file for the HRP textures. No extra license seems required for the music packs.
Created attachment 342456 [details] games-fps/eduke32-20130317.3572-r1.ebuild Here's my updated eduke32 ebuild, based on the current in-tree version. I adds back support for the expansion packs, hi-res textures, etc. Some general comments/questions: * HRP requires it's own license; did I handle that correctly? Don't think I've ever messed with an option license before. * I included to version number in the filenames of the various HRP and music files in order to address Patrick's concern in comment 33. * Why are the gnome2_* functions needed? This package doesn't include any gnome-specific support that I'm aware of. Don't have a problem with them, would just like to understand why you added them. * Sweet - eduke32 now includes unpackssi, so the separate ebuild is no longer needed for installing the expansion packs. I've obsoleted my previous unpackssi ebuild. * It seems it was relatively easy to prevent building of the editor tool, so I included support for that as well. I'll readily admit it's not pretty, but it's effective. Updated expansion pack ebuilds will be forthcoming later this week, but in the meantime I thought I'd upload the based eduke32 one for feedback.
Created attachment 342458 [details] games-fps/duke3d-data-1.0-r2.ebuild Updated duke3d-data ebuild. This includes support for installation from the Atomic Edition CD-ROM, plus it should be a bit more robust.
(In reply to comment #54) > Created attachment 342456 [details] > games-fps/eduke32-20130317.3572-r1.ebuild > > Here's my updated eduke32 ebuild, based on the current in-tree version. I > adds back support for the expansion packs, hi-res textures, etc. Some > general comments/questions: > > * HRP requires it's own license; did I handle that correctly? Don't think > I've ever messed with an option license before. > > * I included to version number in the filenames of the various HRP and music > files in order to address Patrick's concern in comment 33. > > * Why are the gnome2_* functions needed? This package doesn't include any > gnome-specific support that I'm aware of. Don't have a problem with them, > would just like to understand why you added them. > > * Sweet - eduke32 now includes unpackssi, so the separate ebuild is no > longer needed for installing the expansion packs. I've obsoleted my > previous unpackssi ebuild. > > * It seems it was relatively easy to prevent building of the editor tool, so > I included support for that as well. I'll readily admit it's not pretty, > but it's effective. > > Updated expansion pack ebuilds will be forthcoming later this week, but in > the meantime I thought I'd upload the based eduke32 one for feedback. As I was initially suggesting... wouldn't it be possible to outsource all extensions to another ebuild, so that you have less rebuilds? Otherwise you will be rebuilding eduke32 when you want to remove extensions for no reason.
(In reply to comment #56) > As I was initially suggesting... wouldn't it be possible to outsource all > extensions to another ebuild, so that you have less rebuilds? > Otherwise you will be rebuilding eduke32 when you want to remove extensions > for no reason. I guess it's possible, but it would make it (more) needlessly complicated and also work differently than every other game I'm aware of that supports optional textures, music packs, etc. Eg., even the d1x-rebirth ebuild that you worked on recently integrates the optional music packs into the main ebuild. While there's certainly more going on with this ebuild, conceptually I don't see why this would be handled differently. Plus, eduke32 builds and installs, w/ the hires textures, editor, and optionaly tools, in 96 seconds on my 3-year-old desktop. It's not like we're dealing with something like Firefox or Libreoffice here that may take hours to compile, nor would I expect people to frequently decide to change which options they have installed.
Created attachment 342598 [details, diff] files/unpackssi_64bit_fix.patch Included version of unpackssi suffers from same 64-bit issues as the standalone version. As discussed in comment 32, this patch fixes that.
Created attachment 342600 [details] games-fps/eduke32-20130317.3572-r1.ebuild Updated eduke32 ebuild, containing the unpackssi patch and also complete support for the dukedc expansion pack. That ebuild will be posted next, with additional comments.
Created attachment 342602 [details] games-fps/duke3d-dukedc-1.0.ebuild Revised dukedc ebuild, factoring in hasufell's recommendations. This is by far the easiest of the three expansion packs, so before going any further I'd like to reach some kind of agreement on how they should be handled. hasufell, you and I obviously approach this stuff a bit differently, so I'd like to get your take on this. What I've presented here (in terms of the interaction between the eduke3d and dukedc ebuilds) is what I think is the best and most convenient solution for users; all desired options and expansion packs can be installed and setup automatically with one emerge command, all controlled by USE flags. Potential technical issues aside (such as a wrong header or whatever), how does this look to you? Conceptually, is this reasonable enough? If so, I'll proceed with the other two ebuilds. If not... can you give me an alternate suggestion that's as convenient for users? I don't mind changing up my approach, and I'm always happy to improve upon anything I can, but I would like to understand the benefits said alternate approach would provide over this one. Thanks.
please provide a metadata.xml or just the part that describes the useflags, I have no idea how to describe those
Created attachment 342682 [details] metadata.xml attaching updated metadata.xml, as requested. By the way, it looks like the 'server' flag controls all netcode support; ie., without it, you can't join a network game either. If that's the case, would it make sense to change that to 'network', or something along those lines?
slightly different +*eduke32-20130317.3572-r1 (20 Mar 2013) + + 20 Mar 2013; Julian Ospald <hasufell@gentoo.org> + +eduke32-20130317.3572-r1.ebuild, metadata.xml: + add offensive, opl-musicpack, sc55-musicpack, textures useflags wrt #172183 + thanks for the contribution will look at dukedc/unpackssi later
I dont know why it fails. I have tested an older version of nasm but that dont change anything. I never had this error before. Maybe anyone should add nasm USE again than it could be unset. What is wrong? I am using the most recent ebuild here. [32;01m * [39;49;00mPackage: games-fps/eduke32-20130317.3572-r1 [32;01m * [39;49;00mRepository: gentoo [32;01m * [39;49;00mMaintainer: hasufell@gentoo.org games@gentoo.org [32;01m * [39;49;00mUSE: elibc_glibc gtk kernel_linux offensive opengl png sc55-musicpack server textures userland_GNU vpx x86 [32;01m * [39;49;00mFEATURES: sandbox >>> Unpacking source... >>> Unpacking eduke32_src_20130317-3572.tar.bz2 to /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work >>> Unpacking eduke32-icons.tar to /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work >>> Source unpacked in /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work >>> Preparing source in /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572 ... [32;01m*[0m Applying eduke32-20130317.3572-QA.patch ... [A[72C [34;01m[ [32;01mok[34;01m ][0m >>> Source prepared. >>> Configuring source in /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572 ... .......................................................................... make -C build/ "OBJ=../source/eobj" enginelib LUNATIC=0 make[1]: Entering directory `/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572/build' if as -f elf src/a.nasm -o ../source/eobj/a.o; then true; else false; exit 1; fi Assembler messages: Error: can't open elf for reading: No such file or directory src/a.nasm:1: Error: junk at end of line, first unrecognized character is `"' src/a.nasm:2: Error: no such instruction: `ken Silverman's official web site: "http://www.advsys.net/ken"' src/a.nasm:3: Error: no such instruction: `see the included license file "BUILDLIC.TXT" for license info.' src/a.nasm:5: Error: no such instruction: `this file has been modified from Ken Silverman's original release' src/a.nasm:6: Error: no such instruction: `by Jonathon Fowler (jf@jonof.id.au)' src/a.nasm:8: Error: no such instruction: `cpu 586' src/a.nasm:10: Error: no such instruction: `section .text' src/a.nasm:12: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:13: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:14: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:15: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:16: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:17: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:18: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:19: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:20: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:21: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:22: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:23: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:24: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:25: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:26: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:27: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:28: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:29: Error: junk at end of line, first unrecognized character is `%' src/a.nasm:30: Error: junk at end of line, first unrecognized character is `%' .............................................................. src/a.nasm:2523: Error: too many memory references for `mov' src/a.nasm:2524: Error: too many memory references for `shr' src/a.nasm:2525: Error: too many memory references for `add' src/a.nasm:2526: Error: no instruction mnemonic suffix given and no register operands; can't size instruction src/a.nasm:2527: Error: too many memory references for `mov' src/a.nasm:2528: Error: too many memory references for `mov' src/a.nasm:2529: Error: junk `[edi]' after expression src/a.nasm:2529: Error: too many memory references for `mov' src/a.nasm:2530: Error: invalid char '[' beginning operand 2 `[edi+88888888h]' src/a.nasm:2531: Error: junk `voxbegdraw1' after expression src/a.nasm:2534: Error: no such instruction: `cdeclendset 6' src/a.nasm:2538: Error: too many memory references for `mov' src/a.nasm:2539: Error: too many memory references for `shr' src/a.nasm:2540: Error: too many memory references for `add' src/a.nasm:2541: Error: too many memory references for `xor' src/a.nasm:2542: Error: no instruction mnemonic suffix given and no register operands; can't size instruction src/a.nasm:2543: Error: too many memory references for `mov' src/a.nasm:2544: Error: too many memory references for `mov' .............................................................. src/a.nasm:2884: Error: too many memory references for `mov' src/a.nasm:2886: Error: invalid character (0x9) in operand 1 src/a.nasm:2886: Error: no such instruction: `jbf' src/a.nasm:2887: Error: invalid character (0x9) in operand 1 src/a.nasm:2887: Error: no such instruction: `jbf' src/a.nasm:2888: Error: invalid character (0x9) in operand 1 src/a.nasm:2888: Error: no such instruction: `jbf' make[1]: *** [../source/eobj/a.o] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572/build' make: *** [enginelib] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... make[1]: Entering directory `/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572/source/jaudiolib' mkdir -p obj mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/drivers.c -o obj/drivers.o; then true; else false; exit 1; fi if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/fx_man.c -o obj/fx_man.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/multivoc.c -o obj/multivoc.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/mix.c -o obj/mix.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/mixst.c -o obj/mixst.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/pitch.c -o obj/pitch.o; then true; else false; exit 1; fi mkdir -p obj mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/formats.c -o obj/formats.o; then true; else false; exit 1; fi if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/vorbis.c -o obj/vorbis.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/flac.c -o obj/flac.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/driver_nosound.c -o obj/driver_nosound.o; then true; else false; exit 1; fi mkdir -p obj if i686-pc-linux-gnu-gcc -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -std=gnu89 -Wimplicit -Wdeclaration-after-statement -funswitch-loops -fomit-frame-pointer -DNDEBUG -fno-stack-protector -march=pentium3 -mtune=generic -mmmx -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result -Wno-char-subscripts -DUSE_LIBPNG -DUSE_LIBVPX -DHAVE_INTTYPES -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DRENDERTYPESDL=1 -Wstrict-overflow=1 -DUSE_OPENGL -DLINKED_GTK -DPOLYMER -Iinclude -Isrc -DHAVE_VORBIS -DHAVE_FLAC -DHAVE_SDL `pkg-config --cflags vorbis` -Wno-attributes -c src/driver_sdl.c -o obj/driver_sdl.o; then true; else false; exit 1; fi if i686-pc-linux-gnu-ar cr libjfaudiolib.a obj/drivers.o obj/fx_man.o obj/multivoc.o obj/mix.o obj/mixst.o obj/pitch.o obj/formats.o obj/vorbis.o obj/flac.o obj/driver_nosound.o obj/driver_sdl.o; then true; else false; exit 1; fi make[1]: Leaving directory `/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572/source/jaudiolib' [31;01m*[0m ERROR: games-fps/eduke32-20130317.3572-r1 failed (compile phase): [31;01m*[0m emake failed [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=games-fps/eduke32-20130317.3572-r1'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=games-fps/eduke32-20130317.3572-r1'`. [31;01m*[0m The complete build log is located at '/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/temp/environment'. [31;01m*[0m Working directory: '/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572' [31;01m*[0m S: '/var/tmp/portage/games-fps/eduke32-20130317.3572-r1/work/eduke32_20130317-3572'
open a new bug, this bug is for extension ebuilds, not for build time issues
Created attachment 350270 [details] duke3d-data-1.0.ebuild can you give this a test?
What's the status on those caribbean/nwinter/dukedc data ebuilds? nwinter is not a live ebuild so it should not use subversion, can we work around that? caribbean still uses unpackssi
(In reply to Julian Ospald (hasufell) from comment #67) > What's the status on those caribbean/nwinter/dukedc data ebuilds? > > nwinter is not a live ebuild so it should not use subversion, can we work > around that? > > caribbean still uses unpackssi I've been waiting for your response to comment 60, as I don't wish to waste a lot more time on these if you don't like some aspect of what I'm doing. If you're ok with the approach I took for dukedc, I'll go ahead and update the other two to work along the same lines. nwinter didn't have a tarball release last time I looked, so svn was the only option at the time. If that hasn't changed we can probably do a snapshot, but that'll require your assistance/approval to have that snapshot hosted with gentoo. I'll check out the new duke3d-data when I get a chance - should be tonight or tomorrow night.
(In reply to Julian Ospald (hasufell) from comment #66) > Created attachment 350270 [details] > duke3d-data-1.0.ebuild > > can you give this a test? Just tried it (took a little longer to get to than I expected - sorry about that), and it works fine. Only thing I noticed is that, since you've listed each individual file to copy, it doesn't copy over all demo files from my Atomic Edition CD. It grabs demo1.dmo and demo2.dmo, but not gemo3.dmo. This isn't an issue for me as I don't bother with the demos, but it might be for some. Just using demo?.dmo instead of specifying each file individually would fix this. No problems otherwise. Thanks for the update - will be glad to see this in portage with Atomic Edition support. Have you had a chance to review the last dukedc build?
unfortunately I have limited time, so progress is slow here +*duke3d-data-1.0-r1 (28 Jun 2013) + + 28 Jun 2013; Julian Ospald <hasufell@gentoo.org> +duke3d-data-1.0-r1.ebuild: + add support for Atomic Edition wrt #172183
(In reply to Jared B. from comment #68) > (In reply to Julian Ospald (hasufell) from comment #67) > > What's the status on those caribbean/nwinter/dukedc data ebuilds? > > > > nwinter is not a live ebuild so it should not use subversion, can we work > > around that? > > > > caribbean still uses unpackssi > > I've been waiting for your response to comment 60, as I don't wish to waste > a lot more time on these if you don't like some aspect of what I'm doing. > If you're ok with the approach I took for dukedc, I'll go ahead and update > the other two to work along the same lines. > > nwinter didn't have a tarball release last time I looked, so svn was the > only option at the time. If that hasn't changed we can probably do a > snapshot, but that'll require your assistance/approval to have that snapshot > hosted with gentoo. > See if you can rework the remaining ones. No svn ebuilds. Upload snapshots somewhere on googlecode/sourceforge for testing.
I have bought duke3d from gog and added a gog useflag to the data ebuild. Can we get some action here? I'll be able to test stuff properly now.
yeah, should be able to. I actually started working on this again about two weeks ago but then got sidetracked with building a new computer. Think I should have time to at least make the changes we previously discussed in the next few days.
besides you could add an entry of eduke32 here: https://wiki.gentoo.org/wiki/Games/fps
just FYI, haven't forgotten about this. The motherboard for my new computer ended up being a turd and I've wasted a lot of time troubleshooting it and arguing with the vendor. Finally have a (mostly) stable computer again so I'll try again to get something knocked out soon.
Duke Nukem HRP 5.3 is out!
As for the current status, we have an up-to-date version of eduke32 in tree among some packs like HRP. What currently is missing, are those extensions packs like nuclear winter. Since they can't be purchased anymore nor are available on platforms like GOG, I can't much do here, to add the needed 'data' ebuilds for the extension packs. So, as for now, I will close here, as I can't do anything further. Feel free to leave me a note, if you have a source for the extension packs. (In reply to Julian Ospald from comment #72) > I have bought duke3d from gog and added a gog useflag to the data ebuild. In the mean time, support for GOG on duke3d-data has been added. Cheers Conrad
