Created attachment 770951 [details] mac-6.13.ebuild (no working - missing source downloads) Monkey's Audio Codec Home: https://www.monkeysaudio.com Gentoo has available 4.11-r1 released upstream 2018Oct24 (http://gpo.zugaina.org/media-sound/mac) Latest available upstream is 7.59 released 2022Apr12. (https://www.monkeysaudio.com/versionhistory.html) Upstream does not maintain historical build sources. Rolling-Release/latest only available. Debian does make available via deb-multimedia(https://www.deb-multimedia.org/pool/main/m/monkeys-audio-dmo/). It appears org has restructured layout access to package (old available at ...pool/main/m/monkeys-audio/ while current is stored at pool/main/m/monkeys-audio-dmo/). debain old-stable(buster): 4.11 released upstream 2018Oct24 debain stable(bullseye): 6.37 released upstream 2021Jul19 debain testing(sid): 7.59 released upstream 2022Apr12 Have a local ebuild for version 6.13 (released upstream 2021Feb24) that builds cleanly however historical zip is no longer available. Bumping revision fails as source has changed structure. Unable to resolve handling of common header files (srd_dir/Source/*.h files). Bumping revision to at least 6.37 would seem best. https://www.deb-multimedia.org/pool/main/m/monkeys-audio-dmo/monkeys-audio_6.37-dmo1_amd64.deb
* edit: ...common header files (src_dir/Source/*.h files).
I am aware of the newer versions. I already have an ebuild locally. If you make it work with the reverse dependencies I will gladly add it to the tree. Another option would be removing mac audio support from aqualung. Don't know if there are other consumers actually.
media-sound/flacon also has a dependency on media-sound/mac. Confident there are others. At least 6.37 to be consistent with debian stable would be useful.
Appreciation to pg_overlay (https://gitlab.com/Perfect_Gentleman/PG_Overlay). Overlay had updated ebuild for version 7.60. Same ebuild can be utilized for latest version available from upstream (v 9.04) Ebuild appears to work locally.
Created attachment 849151 [details] ebuild for latest release (v9.04) available upstream
I also have an ebuild here which works fine on it's own. However aqualung does not build against it. I did not test but I guess it is the same for flac. Looking at that ebuild it will be the same as some patching will be required or flac and aqualung upstream need to make it work with the newer versions of mac.
Version Bump - 10.09 Upstream changed to CMake building @9.15 release. Ebuild attached.
Created attachment 860172 [details] ebuild - mac-10.09
Created attachment 867443 [details] Ebuild file ebuild v10.17 Monkey's Audio Codec (June 29, 2023). Same as previous attachment (v10.09).
This is just a heads up. I am planning on bumping media-sound/mac to a recent version [1] to fix this bug. As the current version is rather ancient things might break. I already adapted media-sound/aqualung [2] to work with the newer version. A quick search retuned the following packaged depending on media-sound/mac: media-sound/abcde sound@gentoo.org media-sound/asunder sound@gentoo.org media-sound/dir2ogg sound@gentoo.org media-sound/flacon rndxelement@protonmail.com proxy-maint@gentoo.org media-sound/shntool sound@gentoo.org media-sound/xmms2 ionen@gentoo.org Maybe it is a good idea to check the compatibility with newer versions. I guess it will be easier if I add a masked version first. [1] https://monkeysaudio.com/developers.html [2] https://github.com/jeremyevans/aqualung/commit/a991c13d0df734a5d0fea7db6b181176858f3e58
Seems like this is going to need extra work. First soname changed, but no subslot nor := are setup to trigger rebuilds with this package atm. ...but there's also the two-state thing (mac vs MAC) meaning odds are most revdeps can only build against one or the other (unless build system has some magic to detect both), so subslot rebuilds may not really be useful given can't switch back&forth. Think simplest would be to revbump current revdeps depend on <mac-10 or so, then we can later make fixed ones that depend on the new one. Given mac is optional in all these packages (and off by default, plus kind of niche), the bounds may not come as "too" annoying until things are sorted.
(In reply to Ionen Wolkens from comment #11) > [..] so subslot rebuilds may not really be useful Then again it looks like it goes from so.9 to so.10, to probably so.11 with every versions. So subslot rebuilds should probably be setup anyway.
On another note, slotting the old one would also be technically possible. There is only 1 (one) file that conflicts and it's /usr/bin/mac (libraries and includes don't). Albeit this may not be worth the trouble.
(In reply to Daniel Pielmeier from comment #10) > media-sound/xmms2 ionen@gentoo.org All this aside, as far as I'm concern, this one does not need to be fixed. Will sooner mask the USE. Not to say slyfox (current kinda upstream, but mostly for life support) may or may not be interested.
Hey Ionen! Thank you very much for your feedback. I was also wondering about the proper course of action. This why I added all the maintainers of packages depending on mac. (In reply to Ionen Wolkens from comment #11) > Seems like this is going to need extra work. > > First soname changed, but no subslot nor := are setup to trigger rebuilds > with this package atm. > Thanks, I also had subslots in mind. > ...but there's also the two-state thing (mac vs MAC) meaning odds are most > revdeps can only build against one or the other (unless build system has > some magic to detect both), so subslot rebuilds may not really be useful > given can't switch back&forth. I was also not sure about the change in library name. At least the changes for aqualung are not backwards compatible. I was able to convince the upstream maintainer in that regard. Didn't think it was worth the trouble. > Think simplest would be to revbump current revdeps depend on <mac-10 or so, > then we can later make fixed ones that depend on the new one. Given mac is > optional in all these packages (and off by default, plus kind of niche), the > bounds may not come as "too" annoying until things are sorted. Makes sense. (In reply to Ionen Wolkens from comment #12) > (In reply to Ionen Wolkens from comment #11) > > [..] so subslot rebuilds may not really be useful > Then again it looks like it goes from so.9 to so.10, to probably so.11 with > every versions. So subslot rebuilds should probably be setup anyway. Soname for the current version is 2.0.0. It will definitely change again for the newer versions. There were already a few changes in soname to get to .10. (In reply to Ionen Wolkens from comment #13) > On another note, slotting the old one would also be technically possible. > There is only 1 (one) file that conflicts and it's /usr/bin/mac (libraries > and includes don't). Albeit this may not be worth the trouble. Agreed :-) So what about proceeding as follows: - revbump all reverse dependencies to depend on <media-sound/mac-4.12 - add the new version with subslot 0/10 - new versions then have to use properslot operators if they are compatible Does this make sense or am I missing something?
(In reply to Daniel Pielmeier from comment #15) > So what about proceeding as follows: > - revbump all reverse dependencies to depend on <media-sound/mac-4.12 > - add the new version with subslot 0/10 > - new versions then have to use properslot operators if they are compatible > > Does this make sense or am I missing something? Haven't thought about it that much, but sounds fine to me.
(In reply to Ionen Wolkens from comment #16) > (In reply to Daniel Pielmeier from comment #15) > > So what about proceeding as follows: > > - revbump all reverse dependencies to depend on <media-sound/mac-4.12 > > - add the new version with subslot 0/10 > > - new versions then have to use properslot operators if they are compatible > > > > Does this make sense or am I missing something? > Haven't thought about it that much, but sounds fine to me. Okay, thank you! If there are no objections/concerns, I will do this after giving everyone enough time to respond here.
Just a final heads up. I will pin the versions of the reverse dependencies in the next few days and then bump mac. Any reason for three stable versions of flacon? I will also remove the old versions if nobody objects. It seems all of them are affected by bug #831592.