I added HOME/.local/share/SRB2 originally to allow user to have their assets
locally, but this is not needed anymore.
And I tried the game and it segfaults for me too, which is weird, bcs on
7.0-stable it ran fine (as I said in first letter). Maybe there are issues with
recent libraries or something. I'll try to debug this, thanks!
Regards,
Leo.
On 6 December 2021 14:44:13 UTC, Omar Polo <o...@openbsd.org> wrote:
>Omar Polo <o...@openbsd.org> writes:
>
>> la-ninpre <aa...@aaoth.xyz> writes:
>>
>>> Hi,
>>> I ported the game Sonic Robo Blast 2 to OpenBSD and also Game
>>> Music
>>> Emu library that is required for music in this game to work.
>>>
>>> It would be nice if someone can test it. I've already run it
>>> successfully on 7.0-current and also another person tried it on
>>> i386 architecture.
>>>
>>> I was unsure about distribution of game assets, so i followed
>>> approach
>>> similar to other game ports: only game binary is distributed and
>>> user
>>> is supposed to download and install game assets by themselves.
>>>
>>> Anyway, all input is welcome!
>>>
>>> Regards,
>>> Leo.
>>
>> Hello,
>>
>> regarding libgme:
>>
>> the ports looks fine. I'd only tweak the order of the variables as per
>> Makefile.template (i.e. DISTNAME at the top, the SHLIBS, CATEGORIES,
>> HOMEPAGE...). SEPARATE_BUILD is already implied by the use of cmake;
>> CONFIGURE_ARGS is usually lay down a bit differently and I can't find
>> them grepping the sources (and cmake warns about unused defines);
>> CMAKE_INSTALL_PREFIX is not needed. The code is (seems) C++11, so let's
>> add a comment about that before the COMPILER line and drop base-gcc from
>> the list. I'd add a NO_TEST=Yes since there aren't any tests.
>>
>> Otherwise builds fine on amd64.
>>
>> I'd drop the "Use CMake to build" from pkg/DESCR, as I don't think the
>> build system used is an important info for DESCR.
>>
>>
>> regarding srb2:
>>
>> ports looks fine too, but most of the previous point applies here as
>> well. In addition, DISTNAME is not needed when using GH_TAGNAME (it's
>> only when you need to use GH_COMMIT otherwise the tarball ends up with a
>> weird name.) CMAKE_BUILD_TYPE is already taken care of by modcmake, as
>> well as CMAKE_INSTALL_PREFIX. I'd explicitly disable ccache for cmake,
>> that's already taken care by the port infrastructure. The port is a C
>> one and since COMPILER is the default I guess we can drop it. We can
>> always revisit this if it fails the builds on gcc arches.
>>
>> We usually don't hardcode /usr/local, so in patch-src_sdl_i_system_c I
>> went with ${PREFIX} + SUBST_CMD in pre-configure. We also need to tweak
>> PATCHORIG otherwise `make update-patches' picks up stuff that isn't ours.
>>
>> Regarding the assets: IANAL but I see that other distributions packages
>> those too (either in the srb2 package or in a -data subpackage.) There
>> is a file with the thirdy parties licenses[0] and it list all "OKish"
>> licenses. With the assets the package weight a bit more, it's around
>> 180M, maybe we could split it. (and dropped the README at this point)
>>
>> Attaching the updated tarballs as per previous notes. I've only opened
>> the menu (no time to play today :/) but it's OK op@ to import if someone
>> does some testing. I'll do some proper testing in the following days ;)
>
>I was probably a little too optimistic ;-)
>
>la-ninpre noted off-list that now that we're fetching the assets there's
>no need to list the hashes in assets/CMakeList.txt and that we can avoid
>rm(1)'ing files in post-extract by tweaking the EXTRACT_CASES: we're
>only interested in the .pk3 and .dta files, it should save a bit of
>space during builds I guess.
>
>I forgot to sort WANTLIB in previous submission and when tweaking
>patch-src_sdl_i_system_c I haven't noticed that it was adding
>HOME/.local/share/SRB2: upstream doesn't do that and I don't see any
>reason to add an extra search path.
>
>I tried to play the game but it always segfaults, either in the first
>level or in the tutorial, after a couple of seconds. It doesn't leave
>any core files around (it seems to trap SIGSEGV) and it quits with a
>'got signal 5' (which is SIGTRAP) when started from egdb. FWIW, I'm
>running on amdgpu.
>
>Probably not too hard to debug, but I don't have time for that atm.
>Attaching an updated tarball with the above point addressed and
>DEBUG_PACKAGES set, should aid the debugging.
>
