"Emulates an AirPort Express for the purpose of streaming music from iTunes and compatible iPods" see: http://mafipulation.org/blagoblig/reversing/index.html#shairport This library is a dependency for xbmc-9999 and the upcoming eden release and enables the builtin airport support in XBMC. Since Gentoo wants to have each dependency as a seperate ebuild, we should split libshairport from xbmc and offer it as a dedicated package. Therefore I rolled an ebuild, which is based on the sources found at http://mirrors.xbmc.org/build-deps/darwin-libs/. XBMC needs a spcific version and patches in order to work, please see http://forum.xbmc.org/showpost.php?p=902459&postcount=2 and https://github.com/xbmc/xbmc/tree/master/lib/libshairport (patches). Please see attachement for the ebuild. It would be nice to find a maintainer soon to get this ebuild into the official tree. Currently libshairport gets build fine, although configure phase of xbmc will not recognize the installed lib on gentoo due to --as-needed. Until now I wasn't able to fix it by following the "--as-needed guide" (http://www.gentoo.org/proj/en/qa/asneeded.xml) Reproducible: Always Steps to Reproduce: 1. emerge xbmc-9999 Actual Results: 1. configure phase tells me it has no builtin nfs support Expected Results: 1. configure phase should tell me it has builtin nfs support
Created attachment 289661 [details] libshairport-1.2.0.20310.ebuild
wrong: > Steps to Reproduce: > 1. emerge xbmc-9999 > Actual Results: > 1. configure phase tells me it has no builtin nfs support > > Expected Results: > 1. configure phase should tell me it has builtin nfs support right: Steps to Reproduce: 1. emerge xbmc-9999 Actual Results: 1. configure phase tells me it has no builtin airport support Expected Results: 1. configure phase should tell me it has builtin airport support
> Currently libshairport gets build fine, although configure phase of xbmc will > not recognize the installed lib on gentoo due to --as-needed. Until now I > wasn't able to fix it by following the "--as-needed guide" > (http://www.gentoo.org/proj/en/qa/asneeded.xml) What worked is to filter --as-needed in the xbmc ebuild by adding: inherit flag-o-matic ... pkg_setup() { append-ldflags $(no-as-needed) } But I assume this is not "the way of gentoo". :)
commit https://github.com/xbmc/xbmc/commit/40ab15b1cb6e6c868d6b5ac2f295807741e902f4 fixed the build issue.
Comment on attachment 289661 [details] libshairport-1.2.0.20310.ebuild airtunes support is optional, so having this in the tree isn't a real requirement as for the ebuild: - there's no need for the tarball renaming in SRC_URI - delete empty DEPEND/RDEPEND - set S= in global scope rather than src_unpack - you should list explicit patches rather than globing them all
Created attachment 305103 [details] libshairport-1.2.0.20310.ebuild
Created attachment 305105 [details] libshairport-9999.ebuild
Created attachment 305107 [details, diff] 01-libshairport-1.2.0.20310-add_ao.patch
Created attachment 305109 [details, diff] 02-libshairport-1.2.0.20310-fix_install_header.patch
Created attachment 305111 [details, diff] 03-libshairport-1.2.0.20310-fix_deadlock.patch
Created attachment 305113 [details, diff] 04-libshairport-1.2.0.20310-fix_bad_access.patch
Created attachment 305115 [details, diff] 05-libshairport-1.2.0.20310-fix_shutdown.patch
Created attachment 305117 [details, diff] 06-libshairport-1.2.0.20310-no_printf.patch
Created attachment 305119 [details, diff] 07-libshairport-1.2.0.20310-fix_syslog_defines.patch
Created attachment 305121 [details, diff] 08-libshairport-1.2.0.20310-add-missing-libs.patch
All fixed, though not sure about the $S. Just have a look at it. You are right libshairport is optional for xbmc. However I think it would be a really nice addon for a media center.
Created attachment 314475 [details] updated libshairport-1.2.0.20310.ebuild - inherit eutils - added ipv6 patch from team xbmc - added metadata patch from team xbmc
Created attachment 314477 [details] libshairport-9999.ebuild - inherit eutils - added ipv6 patch from team xbmc - added metadata patch from team xbmc
Created attachment 314479 [details, diff] 09-libshairport-1.2.0.20310-fix-ipv6.patch
Created attachment 314481 [details, diff] 10-libshairport-1.2.0.20310-handle-metadata.patch
Created attachment 314547 [details, diff] 10-libshairport-1.2.0.20310-handle_metadata.patch
Created attachment 314549 [details, diff] 09-libshairport-1.2.0.20310-fix_ipv6.patch
Created attachment 314551 [details, diff] 08-libshairport-1.2.0.20310-add_missing_libs.patch
Created attachment 314553 [details] libshairport-1.2.0.20310.ebuild - removed live ebuild, just rename to *-9999.ebuild in order to obtain the live sources. XBMC needs PV 1.2.0.20310 - moved inherit eutils to else clause - removed globbing from patches - corrected patch names
Created attachment 314569 [details] libshairport-1.2.0.20310.ebuild - removed testing echo "${S}" - moved ${S} to global scope - negative if clause for epatch (!= "9999")
Comment on attachment 314569 [details] libshairport-1.2.0.20310.ebuild inherit vcs-snapshot rather than mucking with S yourself can't you get these patches merged upstream ?
(In reply to comment #26) > Comment on attachment 314569 [details] > libshairport-1.2.0.20310.ebuild > > inherit vcs-snapshot rather than mucking with S yourself You mean something like below? SRC_URI="http://mirrors.xbmc.org/build-deps/darwin-libs/${P}_lib.tar.gz -> ${P}.tar.gz" > can't you get these patches merged upstream ? The point is I took the patches from team xbmc found over here: https://github.com/xbmc/xbmc/tree/master/lib/libshairport All I wanted to achive is to create an ebuild providing a version of libshairport playing together with xbmc nicely. So I referred to the snapshot of team xbmc and their patches rather than to the git sources. (see post #1) So afait team xbmc already cares about getting the patches merged upstream. At least it looks like some of them were already merged according to the commit log: https://github.com/amejia1/libshairport
Created attachment 314923 [details] libshairport-1.2.0.20310.ebuild - add openssl as a dependency - assign value to $S (S="${WORKDIR}/${P}_lib")
Any news here? This would be a nice addition, and it seems like we're really close!
(In reply to comment #29) > Any news here? This would be a nice addition, and it seems like we're really > close! Can't tell you anything about an approval to get this into the tree. But personally I haven't been able to improve or to keep the ebuild in sync since my last changes due to time constraints. And it looks like I will not have time during the next months to do so.
also needed for the up and coming plex hometheater linux client, i changed the ebuild to -9999 an the live version is missing libao dependencie but compiles fine! please add to tree !
Created attachment 339194 [details, diff] 11-libshairport-1.2.0.20310-ipv4_fallback.patch
Created attachment 339196 [details] libshairport-1.2.0.20310.ebuild Updated epatch section
I just wanted to emphasize: Although airplay can live without airtunes (libshairport), it will not play back pure audio streams in that case. It will stream videos with audio, pictures, but not pure audio data. The other way 'round, airtunes will not do anything with the absence of airplay. So in order to get the full enjoyment of streaming all kinds of media we will need both airplay and airtunes. This might seem to be strange because airplay is the successor of airtunes and is able to stream the full spectrum of available media on Apple devices. But I **assume** (I really don't know tbh) airplay is based on an enhanced airtunes codebase, so again under the hood we might have both airplay and airtunes again. http://en.wikipedia.org/wiki/AirPlay
Created attachment 339570 [details, diff] Enhances xbmc-9999.ebuild to enable airtunes/libshairport
(In reply to comment #26) > Comment on attachment 314569 [details] > libshairport-1.2.0.20310.ebuild > > can't you get these patches merged upstream ? Meanwhile all of them seem to be merged upstream, see: https://github.com/amejia1/libshairport So using the live ebuild would use the patched sources from upstream. The point is they don't have tags/releases we could use for a non-live ebuild. Not sure about how Gentoo handles such cases.
I just thought I'd update this based on brief discussion I had with the upstream (link: http://forum.xbmc.org/showthread.php?tid=157025 ). This ebuild, while completely necessary for airplay (airtunes specifically) to function, is not actually "libshairport", but rather the XBMC patched version of the library, which is on the roadmap for deprecation within XBMC. I would argue that if this ebuild were to be included, it should be re-labeled xbmc-libshairport rather than libshairport which might be confusing. Additionally, it should be removed from the portage tree entirely once it's been properly deprecated in XBMC.
(In reply to comment #37) > I just thought I'd update this based on brief discussion I had with the > upstream (link: http://forum.xbmc.org/showthread.php?tid=157025 ). > > This ebuild, while completely necessary for airplay (airtunes specifically) > to function, is not actually "libshairport", but rather the XBMC patched > version of the library, which is on the roadmap for deprecation within XBMC. > > I would argue that if this ebuild were to be included, it should be > re-labeled xbmc-libshairport rather than libshairport which might be > confusing. Additionally, it should be removed from the portage tree entirely > once it's been properly deprecated in XBMC. Thank you very much for clearing things up! I completely agree with your last comment. I'm going to attach an updated ebuild in a few minutes. It will only support the git master branch and a git snapshot which we can nail down to a specific commit, e.g. media-plugins/xbmc-libshairport-1.2.0.20310_pre21022013.ebuild So I completely dropped the patches and the source of the original code and added libao dependency.
Created attachment 339574 [details] Updated ebuild to include libao as a dependency. Drops support for original unmaintained upstream source.
Created attachment 339576 [details, diff] Patch for xbmc-9999.ebuild
Would it make sense to rename the ebuild to media-plugins/xbmc-addon-libshairport-1.2.0.20310_pre21022013.ebuild since there is already media-lugins/xbmc-addon-xvdr?
Created attachment 339620 [details] xbmc-addon-libshairport-1.2.0.20310_pre20130221.ebuild - Corrected timestamp in ebuild name according to gentoo policies - Renamed ebuild to match existing xbmc addons in portage tree
Created attachment 339622 [details, diff] xbmc-9999.ebuild.airtunes.patch - Applied changes from libshairport ebuild to xbmc-9999 patch
Created attachment 339686 [details] xbmc-addon-libshairport-1.2.0.20310_pre20130221.ebuild - Removed $S - Removed unnecessary else-statement for EGIT_REPO_URI
(In reply to comment #37) > I just thought I'd update this based on brief discussion I had with the > upstream (link: http://forum.xbmc.org/showthread.php?tid=157025 ). > > This ebuild, while completely necessary for airplay (airtunes specifically) > to function, is not actually "libshairport", but rather the XBMC patched > version of the library, which is on the roadmap for deprecation within XBMC. > > I would argue that if this ebuild were to be included, it should be > re-labeled xbmc-libshairport rather than libshairport which might be > confusing. Additionally, it should be removed from the portage tree entirely > once it's been properly deprecated in XBMC. FYI I just submitted an ebuild for libairplay: https://bugs.gentoo.org/show_bug.cgi?id=458734
Created attachment 339694 [details] xbmc-addon-libshairport-1.2.0.20310_pre20130221.ebuild - Fixed date format in $MY_PV
This ebuild is obsolete since upstream has merged the unified airplay branch into master. Details: https://github.com/xbmc/xbmc/pull/2631 An ebuild for libshairplay is available in this bug report: https://bugs.gentoo.org/show_bug.cgi?id=458734
