P-UAE, a fork and successor to the long abandoned E-UAE is available from here: http://github.com/GnoStiC/ The repository can be reached here: https://github.com/GnoStiC/PUAE.git Unfortunately GnoStiC is committing to this repository, so while it is versioned, it *is* a life ebuild. I have no idea whether this means the ebuild has to be versioned -9999 or not. Therefore I decided to use the official version.
Created attachment 259814 [details] *life* ebuild, the version is the one used by the dev This is a basic ebuild, that works on amd64. I did not have the time to test on x86, yet. There are a lot of use flags, but I haven't tested all of them. Untested USE Flags are: cd32, cdtv, drvsnd, enforcer, gayle, ncr, profiling and scsi-device. USE flags jit, natmem and noflags are restricted to x86, so I can't test them right now.
Created attachment 259815 [details] metadata file explaining the (many) USE flags metadata file explaining the (many) USE flags. I have added myself in the maintainer field to stop the ebuild program to complain about an invalid metadata.xml while testing.
I think a good PV might be 2.3.1_pre9999, at least until the development for 2.3.1 stalls. But best ask upstream. And tell him the commit message is for.
Created attachment 259943 [details] Rename and two changes Thanks for the hint, I renamed the ebuild accordingly. As far as I can tell from upstreams websites and README, the "Version" 2.3.1 refers to the merged WinUAE version. Change one: configure fails if gtk or qt ui is chosen, but threads support disabled. The ebuild now enables thread support if needed but not chosen. Change two: As far as I can tell from the documentation and autotool files, X11 can be used for output as well, so it is added. (But not tested yet)
Can anyone get this to compile now? I've tried using the ebuild and building manually, with various different options for GUI, graphics and sound, and even tried both GCC 4.5 and 4.4. Everything I try, though, results in a (usually different) compile failure. Anyone else have better luck?
(In reply to comment #5) > Can anyone get this to compile now? I've tried using the ebuild and building > manually, with various different options for GUI, graphics and sound, and even > tried both GCC 4.5 and 4.4. Everything I try, though, results in a (usually > different) compile failure. Anyone else have better luck? I haven't had a look at PUAE for quite a while, but I'll see what I can do in the next few days.
I have no real result, yet. It *seems* like these errors are meaning an incompatibility with gcc-4.4+. But I have not much spare time right now.
I tried to compile the package with: - i686-pc-linux-gnu-4.5.3 - i686-pc-linux-gnu-4.3.4 Both failed. I'll attach the full log-file. Also there might be a harmless flag-bug, as the log mentions "* -> ncurses USE flag ignored". Sounds to me like the ncurse-flag could be removed.
Created attachment 292617 [details] Log-File of failed compilation with gcc-4.3.4
(In reply to comment #8) > I tried to compile the package with: > > - i686-pc-linux-gnu-4.5.3 > - i686-pc-linux-gnu-4.3.4 > > Both failed. I'll attach the full log-file. Also there might be a harmless > flag-bug, as the log mentions "* -> ncurses USE flag ignored". Sounds to me > like the ncurse-flag could be removed. This is bad, it was my best guess so far. The line saying that the ncurses USE flag is ignored, is printed by the ebuild because you selected SDL, which is used then. However, I *think* I have found both culprits. A) The version of unzip.h in src/archivers/zip/ is wrong, and B) the bsdsock emulation is no longer optional. I am currently testing a patch and corresponding ebuild and will update my overlay if everything looks good and post both the patch and ebuild here, too, when they are ready.
Sounds great. Thanks for working on this. I tried messing with it some more myself last weekend, but still didn't have any luck.
Created attachment 293227 [details] New ebuild fixing some problems in the current git repo This is the fixed ebuild for the current P-UAE-Version, also available from my overlay (layman -a seden). Change 1: The bsdsock USE-Flag has been removed, building the BSD Socket-Emulation does not seem to be optional any more. Change 2: Added a patch that fixed the borked unzip.h in src/archivers/zip Change 3: Added a patch that adds a delay of 1 second before the two cpudefs.c files are built. With parallel build it happened on my laptop that the build68k tools was called before it was ready. I have successfully built and installed P-UAE with this ebuild and the two patches (to be uploaded next) with these settings: gcc: 4.5.3-r1 P-UAE USE Flags: "X -a2065 -a2091 alsa -amax audio -cd32 -cdtv debugger dga -drvsnd -enforcer fpu -gayle gtk -jit natmem -ncr ncurses -noflags -profiling -qt save-state -scsi-device sdl sdl-gfx -sdl-gl -sdl-sound threads ui -vidmode xarcade" --- Note: I never had time to really test all those USE Flags. If you find one absolutely not working, but think you need it, please let me know! Note 2: I'll inform Mustafa (upstream) of the borked unzip.h tomorrow
Created attachment 293229 [details, diff] Fix borked unzip.h patch
Created attachment 293231 [details, diff] Add a delay before tools/build68k is used patch
I think this bug can be closed. P-UAE is currently synced with WinUAE at version 2.5.1. I am working on cleaning up the code at this location: https://github.com/Yamakuzure/PUAE (We merge each others repositories frequently to keep up with each others work. My cleaning and his enhancements.) Once this is done I'll ask the original Developer, Mustafa Tufan, whether he'd like to start using tags. Then I'll post another ebuild. Using tags should make it possible to use regular versioned ebuilds without packaged sources, right?
(In reply to Sven Eden from comment #15) > I think this bug can be closed. > > P-UAE is currently synced with WinUAE at version 2.5.1. I am working on > cleaning up the code at this location: > > https://github.com/Yamakuzure/PUAE > (We merge each others repositories frequently to keep up with each others > work. My cleaning and his enhancements.) > > Once this is done I'll ask the original Developer, Mustafa Tufan, whether > he'd like to start using tags. Then I'll post another ebuild. > > Using tags should make it possible to use regular versioned ebuilds without > packaged sources, right? Still ongoing? Given that uae and e-uae do both seem dead and this is the only general purpose Amiga emulator left, I think we should try and get it into portage.
(In reply to Roc Vallès from comment #16) > Still ongoing? Given that uae and e-uae do both seem dead and this is the > only general purpose Amiga emulator left, I think we should try and get it > into portage. Unfortunately I had no time for P-UAE all year since april. But it is still developed. I plan to do another round of cleanup on the current P-UAE tree in the first three weeks of january. I can then do signed tagging on my fork and provide tarballs.
(In reply to Sven Eden from comment #17) > (In reply to Roc Vallès from comment #16) > > Still ongoing? Given that uae and e-uae do both seem dead and this is the > > only general purpose Amiga emulator left, I think we should try and get it > > into portage. > > Unfortunately I had no time for P-UAE all year since april. But it is still > developed. > > I plan to do another round of cleanup on the current P-UAE tree in the first > three weeks of january. I can then do signed tagging on my fork and provide > tarballs. Looking forward to that! :)
Ping. Would really like to see this in the tree, given that e-uae hasn't been maintained for some eight years now.
P-UAE has been abandoned, and the much better fs-uae is in my overlay (seden via layman) I'll file a bug for fs-uae soon, and am closing this one as invalid.
