Created attachment 426032 [details] pulseaudio-dlna-0.4.7.ebuild https://github.com/masmu/pulseaudio-dlna A lightweight streaming server which brings DLNA / UPNP and Chromecast support to PulseAudio and Linux. (ebuild and desktop file attached) Only tested with Onkyo and Samsung devices but works really well. Thanks :)
Created attachment 426034 [details] pulseaudio-dlna.desktop
Created attachment 426048 [details] pulseaudio-dlna-0.4.7-r1.ebuild Updated ebuild to create the pulseaudio-dlna.desktop file in ebuild. As it's more of a daemon style application, don't make it possible for the user to start multiple instances of it. Instead start it once at desktop login via XDG autostart in a similar way to rygel.
doesn't work until I rebuild dev-libs/protobuf with python flag enabled After that playback is fine on my chromecast audio device.
Hello, Are you interested in proxy maintaining this package? Proxy-maintainership enables you, a non-developer, to maintain a package in the main repo with the help of willing developers. Check out [1] for more information about the project. If you are interested in proxy-maintaining this package, let me know and I'll officially bring the project in to help. If you choose to proxy the package, you may seek help on maintenance of your package here, via email @ proxy-maint@gentoo.org, and/or join #gentoo-proxy-maint on Freenode IRC. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers
Created attachment 426938 [details] pulseaudio-dlna-0.4.7-r2.ebuild Added dev-libs/protobuf[${PYTHON_USEDEP}] to RDEPEND.
(In reply to NP-Hardass from comment #4) > Hello, > > Are you interested in proxy maintaining this package? Proxy-maintainership > enables you, a non-developer, to maintain a package in the main repo with > the help of willing developers. Check out [1] for more information about > the project. If you are interested in proxy-maintaining this package, let me > know and I'll officially bring the project in to help. If you choose to > proxy the package, you may seek help on maintenance of your package here, > via email @ proxy-maint@gentoo.org, and/or join #gentoo-proxy-maint on > Freenode IRC. > > [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Be happy to, it's a really active project and I use this almost daily now. Only problem I foresee is that I can only test DLNA as I don't own any Chromecast hardware. However Egor may be able to help too in this regard if so inclined.
(In reply to Rick Harris from comment #6) > (In reply to NP-Hardass from comment #4) > > Hello, > > > > Are you interested in proxy maintaining this package? Proxy-maintainership > > enables you, a non-developer, to maintain a package in the main repo with > > the help of willing developers. Check out [1] for more information about > > the project. If you are interested in proxy-maintaining this package, let me > > know and I'll officially bring the project in to help. If you choose to > > proxy the package, you may seek help on maintenance of your package here, > > via email @ proxy-maint@gentoo.org, and/or join #gentoo-proxy-maint on > > Freenode IRC. > > > > [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers > > > Be happy to, it's a really active project and I use this almost daily now. Welcome aboard :) > > Only problem I foresee is that I can only test DLNA as I don't own any > Chromecast hardware. > However Egor may be able to help too in this regard if so inclined. I also have a chromecast and might be able to set a VM to test it to a chromecast (I have no pulseaudio on my main system and prefer to keep it that way) But as long as you can test everything else except for chromecast support, I think you are in a good place maintenance-wise. Will give your ebuild a lookover shortly.
Hey. Firstly, let me apologize for the delay in getting back to you. I attempted to downgrade my system from ~amd64 to amd64 and blew up my glibc and python, so I have been out of commission. A couple of points to start with: There are versions specified in the requirements list in source, so you should incorporate those into your ebuild, even if a lower version doesn't exist for good measure. Never know how old someone's system might be. SRC_URI="https://github.com/masmu/${PN}/archive/${PV}.tar.gz -> ${PN}-${PV}.tar.gz" Good use of the ->. You want your distfile to be identifiable. Only small note is "${P}" == "${PN}-${PV}" so you can simplify that. I think the desktop file would be better suited as file in ${FILESDIR}. There isn't much gained from keeping it in the ebuild as we aren't taking advantage of the shell and removing it keeps the ebuild much cleaner Installing the desktop is even simpler using dodesktop. Why is it restrict="mirror"? And something for you to look into, are the various codecs runtime required or runtime optional? Great start to an ebuild. Looking forward to your update.
Created attachment 428160 [details] pulseaudio-dlna-0.5.0.1.ebuild (In reply to NP-Hardass from comment #8) > Hey. > Firstly, let me apologize for the delay in getting back to you. I attempted > to downgrade my system from ~amd64 to amd64 and blew up my glibc and python, > so I have been out of commission. > > > A couple of points to start with: > > There are versions specified in the requirements list in source, so you > should incorporate those into your ebuild, even if a lower version doesn't > exist for good measure. Never know how old someone's system might be. > > SRC_URI="https://github.com/masmu/${PN}/archive/${PV}.tar.gz -> > ${PN}-${PV}.tar.gz" > > Good use of the ->. You want your distfile to be identifiable. Only small > note is "${P}" == "${PN}-${PV}" so you can simplify that. > > I think the desktop file would be better suited as file in ${FILESDIR}. > There isn't much gained from keeping it in the ebuild as we aren't taking > advantage of the shell and removing it keeps the ebuild much cleaner > > Installing the desktop is even simpler using dodesktop. > > Why is it restrict="mirror"? > > And something for you to look into, are the various codecs runtime required > or runtime optional? > > Great start to an ebuild. Looking forward to your update. Welcome back! :) I'm working through these points for a new version recently released for this package. Have moved the desktop file out of ebuild back into $FILESDIR. Trying the 'dodesktop' function in ebuild I get 'dodesktop: command not found'. Do you have an example for the use of dodesktop, I can't find any in the portage tree? RESTRICT="mirror" is set as the ebuild is not in the portage tree and as such it's distfile is not mirrored by Gentoo either. So rather than have the ebuild hit up the Gentoo distfile mirror and fail before it falls through to the proper SRC_URI, I instruct it not to use the mirror. The codecs are runtime required. The source assumes that those codecs will always be available if/when it calls on them, depending on what device it streams to. The author is starting to include preliminary support for ffmpeg/libav in this release so as to reduce the number of runtime dependencies. However it's use as '--encoder-backend=...' at runtime instead of the default individual codec packages is so far a regression (read doesn't work for me). So with that in mind, I've included the conditional RDEPEND on individual codec packages, then ffmpeg, then libav in that order. I've included the changes made so far to the new release ebuild attached.
Created attachment 428162 [details] pulseaudio-dlna.desktop
(In reply to Rick Harris from comment #9) > RESTRICT="mirror" is set as the ebuild is not in the portage tree and as such > it's distfile is not mirrored by Gentoo either. > So rather than have the ebuild hit up the Gentoo distfile mirror and fail > before it falls through to the proper SRC_URI, I instruct it not to use the > mirror. Might as well remove it then since it won't be present in the final submission. > Have moved the desktop file out of ebuild back into $FILESDIR. > > Trying the 'dodesktop' function in ebuild I get 'dodesktop: command not > found'. > Do you have an example for the use of dodesktop, I can't find any in the > portage tree? > Sorry, I meant domenu from the eutils eclass. But thinking about it, don't bother. Did a quick check of packages in the tree. Policy is to insinto /etc/xdg/autostart rather than symlinking. I'd highly recommend running "repoman full" in the package directory. It'll give you information on QA violations. We have that line 3 should be # $Id$ instead of # $Header: $, the current year in copyright, line 1, and that the DESCRIPTION field must be limited to 80 characters (yours is 102 characters). It'll also complain that you need a metadata.xml file, but we can tackle that later.
Created attachment 428164 [details] pulseaudio-dlna-0.5.0.1-r1.ebuild Fixed those changes in pulseaudio-dlna-0.5.0.1-r1.ebuild for review.
Created attachment 433130 [details] pulseaudio-dlna-0.5.2.ebuild Here's my ebuild I used to install pulseaudio-dlna-0.5.2.
(In reply to NP-Hardass from comment #7) > I also have a chromecast and might be able to set a VM to test it to a > chromecast (I have no pulseaudio on my main system and prefer to keep it > that way) I have a chromecast and also use pulse on my laptop so I can test this pretty easily. I'll test the latest ebuild and report back soon.
Created attachment 434596 [details] pulseaudio-dlna.desktop Workaround potential for multiple instances by same user if they login/logout of session multiple times.
Created attachment 434598 [details] pulseaudio-dlna-0.5.2.ebuild * Update to current 0.5.2 version * Include PYTHON_REQ_USE="threads(+)" from Robert's ebuild * Initial inclusion of encoder runtime dependencies for '--encoder-backend={generic,ffmpeg,avconv}' (may need revisiting with useflags) * Depend on media-sound/pulseaudio[dbus] * Include note about pulseaudio dbus module bug at https://bugs.freedesktop.org/show_bug.cgi?id=95470
work for me any idea when you will push it to portage?
(In reply to bdouxx from comment #17) > work for me > > any idea when you will push it to portage? I can't, I only attempted to proxy maintain it. It was up for review by NP-Hardass some months ago but he's gone awol :|
I just took at look at this ebuild. Its pretty good in general but has a couple things: - The pkill in the desktop file is awkward, is there no better way to make sure it doesnt launch many times? - You usually have to have libav/ffmpeg inside a -libav? () libav? () block since they are not binary compatible are you sure this is okay? - Most importantly, >=dev-python/notify2-0.3[${PYTHON_USEDEP}] does not exist in the tree. It needs to be added first.
Created attachment 442444 [details] notify2-0.3.ebuild
Created attachment 442446 [details] pulseaudio-dlna-0.5.2-r1.ebuild
(In reply to Jason Zaman from comment #19) > I just took at look at this ebuild. Its pretty good in general but has a > couple things: > - The pkill in the desktop file is awkward, is there no better way to make > sure it doesnt launch many times? I agree the pkill is not ideal but I've not been able to come up with anything else as robust. > - You usually have to have libav/ffmpeg inside a -libav? () libav? () block > since they are not binary compatible are you sure this is okay? Have uploaded a revision of latest version with 'libav' useflag blocks. > - Most importantly, >=dev-python/notify2-0.3[${PYTHON_USEDEP}] does not > exist in the tree. It needs to be added first. Have uploaded notify2-0.3.ebuild for inclusion. Thanks :)
Looks much better! Just a few comments from looking it over, I have not installed or tested it yet. - The ebuilds should be EAPI 6 now since thats the latest. no reason to do an earlier one. - The python compat in the notify2 ebuild has several that are removed. https://wiki.gentoo.org/wiki/Project:Python/Implementations It should just have python{2_7,3_4,3_5} none of the earlier ones since they're gone. - The python_test() method looks wrong python_execute_function is a python.eclass thing not in the -r1 versions of the eclasses. Also the distutils-r1 eclass (which it is already using) has an "esetup.py" method instead of doing "${PYTHON}" setup.py. That also handles the || die so that is not needed. It should just be: python_test() { esetup.py test } - Did you test this on the ~x64-macos arch? Python itself is not even keyworded on that arch so it should be removed. pulseaudio-dlna ebuild: - EAPI6 again - the pkg_postinst can probably be removed now that the pkill is there. I'll test these out hopefully tonight or on the weekend then we can merge it in :). Are you up for proxy-maintaining these packages? Can you file a proxy-maintainer bug for this too? Thanks for the work!
I'll convert them to EAPI6. Can't recall where I got the notify2 ebuild from but it needs some updating. I'd like to leave pkg_postinst() message in place as it highlights the problem with pulseaudio's current use of dbus. The pkill in desktop file is simply to stop multiple pulseaudio-dlna processes being started (they don't stop on xsession logout) on multiple xsession logins and is separate to pulseaudio's dbus issue. Happy to proxy maintain both packages but I'm still unsure what the process is for proxy maintaining packages. Do I just submit pull requests to portage's github? > Can you file a proxy-maintainer bug for this too? Not sure what you mean by this. Thanks :)
Created attachment 442774 [details] pulseaudio-dlna-0.5.2-r1.ebuild
Created attachment 442776 [details] notify2-0.3.ebuild
so... I might take this on (probably not as a service but just a simple binary).
why is pip needed?
Ok, it's now in tree, not exactly the same, but I'll leave this bug open for now for changes if wanted.
(In reply to Matthew Thode ( prometheanfire ) from comment #29) > Ok, it's now in tree, not exactly the same, but I'll leave this bug open for > now for changes if wanted. Thank you Matthew :) Pip is probably not needed, was only going off the deps. listed in the source's README.md
Created attachment 480622 [details] pulseaudio-dlna.initd openrc-run file
this is already in the tree
