| Summary: | media-libs/fmod-4.44.04: removal (was: version bump) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Patrick McMunn <doctorwhoguy> |
| Component: | New packages | Assignee: | Gentoo Sound Team <sound> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi, erikdenstore+gbugs, mgorny, treecleaner, zlg |
| Priority: | Normal | Keywords: | EBUILD, PMASKED |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Deadline: | 2019-10-07 | ||
| Attachments: | media-libs/fmod-4.44.04.ebuild | ||
|
Description
Patrick McMunn
2013-01-24 01:31:09 UTC
Created attachment 336674 [details]
media-libs/fmod-4.44.04.ebuild
I added "designer" and "tools" USE flags so that, by default, it only installs the required libs and not things that most users will never need or use. Two things I'm unsure of: 1) The correct directory name for the fmoddesigner header files in the include directory, and 2) whether or not adding the LDPATH to the environment directory even accomplishes anything because when I do "env" or "set" in the console, there is no LDPATH environment variable, so it seems to be ignored anyway.
Other than that, everything seems to work great.
By the way, this ebuild also addresses bug 437468. I ran into a binary-only software built against fmod-4.44.07. The ebuild from comment 1 works well for me when renamed to fmod-4.44.20.ebuild (the current version) and SRC_URI is modified as follows: SRC_URI="http://www.fmod.org/download/fmodex/api/Linux/${MY_P}.tar.gz" The old archives also seem to be moved to this location. It's been almost three years and fmod is still sitting at 4.38.02 in ~amd64. The ebuild is also lacking multilib support, which means any game ebuilds that rely on fmod must use the bundled libs instead of setting proper dependencies. I manage a few game ebuilds that depend on fmod (in a personal overlay) and intend to fix the multilib issue. I'll attach my efforts once I produce an ebuild up to today's standards. Ping for the sound team. (In reply to Daniel Campbell from comment #4) > It's been almost three years and fmod is still sitting at 4.38.02 in ~amd64. > The ebuild is also lacking multilib support, which means any game ebuilds > that rely on fmod must use the bundled libs instead of setting proper > dependencies. I manage a few game ebuilds that depend on fmod (in a personal > overlay) and intend to fix the multilib issue. I'll attach my efforts once I > produce an ebuild up to today's standards. > > Ping for the sound team. Correction: fmod ships both types of libs if you're on amd64, so technically it's already multilib. Most consumers of fmod seem to bundle their own versions, which means either lying about versions to suit these packages or allowing them to bundle libraries. The latter seems the least ugly, so all I suggest is the version bump. Since I'm not part of sound team I won't touch it. Yesterday I was looking into updating to a new version of Fmod. Even if Gentoo hadn't updated, I long kept up to date in my local overlay. And the gamerlay also offered a fairly recent version. But when I checked the Fmod website, the only thing available was Fmod Studio which is their new product (well, it's been around for a few years, but Ex is no longer actively developed). It's currently not in portage or in any overlay, and it doesn't appear to be API compatible with the old Fmod Ex product. I could find no links to download the old versions, and attempts to use old ebuilds I had or the one from gamerly proved that the old download links no longer work. The one in Portage is only available because Gentoo mirrors it. I emailed support at the Fmod website asking about access to legacy versions. I also asked about linking directly to the new Fmod Studio for download because currently the website requires registration and login to download the Linux and Mac versions (but not the Windows version). I have yet to receive a reply. I'm also concerned that the new Fmod license may prevent Gentoo from mirroring it because license section 1 part ii says that FMOD may be "distributed as integrated into a Product only". I'm no lawyer, but it may be necessary to get clarification from upstream before allowing new versions subject to the new license to be mirrored. I've exchanged a couple of emails with the developer. He expressed willingness to work something out so end users won't have to sign up, log in, and download files manually while also trying to prevent bots from leeching files off his servers. I'll follow up when I have more info. (In reply to Patrick McMunn from comment #7) > I've exchanged a couple of emails with the developer. He expressed > willingness to work something out so end users won't have to sign up, log > in, and download files manually while also trying to prevent bots from > leeching files off his servers. I'll follow up when I have more info. Patrick, did you ever hear anything about this? I was wondering about building it on ARM, as the sources are available, at least to licensees. I agree that what we have now seems less than legal. (In reply to James Le Cuirot from comment #8) > Patrick, did you ever hear anything about this? I was wondering about > building it on ARM, as the sources are available, at least to licensees. I > agree that what we have now seems less than legal. The last contact I had with the author was in June last year. He said that he was willing to make some arrangements to accommodate the open source community. He had disabled hotlinking files to deter leeching. He had said that he was planning to update the website in a few weeks, and perhaps something could be done during the website update. I failed to follow up with him until your question, so I've now followed up with him and am awaiting a response. (In reply to Patrick McMunn from comment #9) > (In reply to James Le Cuirot from comment #8) > > The last contact I had with the author was in June last year. He said that > he was willing to make some arrangements to accommodate the open source > community. He had disabled hotlinking files to deter leeching. He had said > that he was planning to update the website in a few weeks, and perhaps > something could be done during the website update. I failed to follow up > with him until your question, so I've now followed up with him and am > awaiting a response. Thanks! To give this a bit more context, I've been bumping Bastion and noticed that while the game is proprietary, it does run under Mono with open source components and could potentially run on any Mono-supported platform. There are probably quite a few games like this, although I don't think it would work for anything Unity-based. In this case, the game is launched via a native binary but I noticed that this is very small and figured it was just a wrapper. Sure enough, if you delete this and just start it with "mono Bastion.exe" then it works. There is another hurdle though. Even if we manage to get an ARM build of FMOD, the game also depends on libsteam_api.so and libSteamWrapper.so and I doubt these exist for ARM. I haven't purchased the game through Steam though and I reckon I could create stub versions of these that would allow the game to run. I got a reply from the author a couple of days ago. It looks like downloading the files directly from the site is a no-go. I'm asking for clarification on the EULA about whether or not the files can be mirrored, but it looks like the most likely outcome is that Fmod will probably need to be RESTRICT=fetch and the user informed that they'll have to download it manually from the site. Only the latest version is readily available for download, but the author says that older versions can be obtained if they submit a support request. To be honest, I think there's no reason to expect any progress here after >6.5yrs. Therefore i'm going to last rite FMOD. If someone really wants to see it updated, you're going to have 30 more days to make it happen. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc3f2da0dd392bf70434dfddf49347448f8fe5e1 commit cc3f2da0dd392bf70434dfddf49347448f8fe5e1 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-09-07 07:14:48 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-09-07 07:15:23 +0000 package.mask: Last rite media-libs/fmod Bug: https://bugs.gentoo.org/453748 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/base/package.use.mask | 5 +++++ profiles/package.mask | 7 +++++++ 2 files changed, 12 insertions(+) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c319138dc63e31801464f07d6059d0c9f4e049b1 commit c319138dc63e31801464f07d6059d0c9f4e049b1 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-10-07 08:07:25 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-10-07 08:12:17 +0000 media-libs/fmod: Remove last-rited pkg Closes: https://bugs.gentoo.org/453748 Signed-off-by: Michał Górny <mgorny@gentoo.org> media-libs/fmod/Manifest | 2 -- media-libs/fmod/fmod-4.38.02.ebuild | 59 ------------------------------------- media-libs/fmod/metadata.xml | 8 ----- profiles/package.mask | 7 ----- 4 files changed, 76 deletions(-) |
