New package: cortexcommand-6.2.2

[xolophreny]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES, compiled

Local build testing

• I built this PR locally for my native architecture, x86_64
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • aarch64 (cross)
  • i686 (fails, meson can't find tbb, also doesn't seem to be supported upstream)
  • x86_64-musl (fails, fmod game audio library needs glibc)

Needs #50375 for recent enough LuaJIT, otherwise builds but crashes in use

[Emru1]

Needs https://github.com/void-linux/void-packages/pull/50375 for recent enough LuaJIT, otherwise builds but crashes in use

Oh, that was the reason why it was constantly crashing

[Calandracas606]

686 (fails, meson can't find tbb, also doesn't seem to be supported upstream)

maybe because void's tbb package only builds the python bindings on x86_64*|aarch64*

x86_64-musl (fails, fmod needs glibc)

musl's math.h should contain fmod: https://git.musl-libc.org/cgit/musl/tree/include/math.h#n227 you might need to patch the software to #include <math.h> where fmod is needed

[Bnyro]

musl's math.h should contain fmod

It's about the fmod game audio library (https://www.fmod.com/), not the mathematical function.

[xolophreny]

maybe because void's tbb package only builds the python bindings on x86_64*|aarch64*

Tried adding i686* to that list in tbb template and building tbb-devel, didn't help, still Run-time dependency tbb found: NO (tried pkgconfig), and unfortunately no other ideas

musl's math.h should contain fmod

Yeah sorry wasn't clear enough there, this is indeed about the fmod game audio library which this uses

[Calandracas606]

It's about the fmod game audio library (https://www.fmod.com/), not the mathematical function.

This looks like a proprietary library.

If a binary is bundled in the distfiles, that would make this package nonfree.

additionally, this package being AGPL but using a proprietary binary would make distribution legally dubious.

maybe the package would need to be restricted

[Calandracas606]

Tried adding i686* to that list in tbb template and building tbb-devel, didn't help, still Run-time dependency tbb found: NO (tried pkgconfig), and unfortunately no other ideas

Try adding cmake to hostmakedepends, and/or patching meson.build to use something like this:

tbb_dep = dependency(
  'TBB',
  method : 'cmake',
  modules : [
    'TBB::tbb',
    'TBB::tbbmalloc',
    'TBB::tbbmalloc_proxy',
  ],
  required : true,
)

[xolophreny]

Try adding cmake to hostmakedepends, and/or patching meson.build to use something like this:

Still results in Run-time dependency tbb found: NO (tried cmake)

Fortunately, looks like they only provide fmod blobs for x86_64 and arm64, so I'm assuming that it would fail from that anyway

As for the blobs - asked the devs about it, first reply was that it should be alright to distribute these final useful bits of fmod, and this fmod forum thread seems to suggest so as well as long as it's not the whole library, but uh, I'll agree with that it sounds dubious and package should probably be restricted

[Calandracas606]

As for the blobs - asked the devs about it, first reply was that it should be alright to distribute these final useful bits of fmod, and this fmod forum thread seems to suggest so as well as long as it's not the whole library, but uh, I'll agree with that it sounds dubious and package should probably be restricted

if this is the case, void would not be able to distribute the software under the terms of the AGPL

[github-actions[bot]]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.