http://docs.livestreamer.io/changelog.html#changelog Version 1.12.0 (2015-03-01)
(Proxy maintainer here.) Update is straightforward. No ebuild changes needed. livestreamer-1.11.1.ebuild -> livestreamer-1.12.1.ebuild
NO. ~/cvsPortage/gentoo-x86/net-misc/livestreamer $ l /mnt/gen2/TmpDir/portage/net-misc/livestreamer-1.12.1/work/livestreamer-1.12.1/ AUTHORS.rst CONTRIBUTING.rst LICENSE.flashmedia MANIFEST.in docs requirements-docs.txt setup.py tests win32 CHANGELOG.rst LICENSE LICENSE.pbs README.rst examples setup.cfg src tox.ini There are 3 separate features of the source here being ignored; docs, examples and tests. This is a minimal ebuild and therefore denying yourself and any user of the opportunity and the choice of reading the docs (provided in the source), perusing and trying the exe python script file gst-player.py, and finally the testsuite is ignored. Testsuites are written by authors for a purpose. Perhaps someone else can run a copy paste commit, not I. Also, the only stabled version was entered *livestreamer-1.7.2 (29 Dec 2013) and there are 7 more piled up since then. What is missing here is a full and proper ebuild and any form of management of the bumped releases. I suggest you make a selection of a recent version and submit a stable request to update the stabled version, any of us can CC arches, and provide a list of old versions to be purged. In the case that you don't know how to write in the new features, that is not an insurmountable problem. You can I suppose insist on the skipping of all of the above.
Created attachment 400188 [details, diff] Patch against livestreamer-1.11.1.ebuild > AUTHORS.rst CONTRIBUTING.rst LICENSE.flashmedia MANIFEST.in docs > requirements-docs.txt setup.py tests win32 CHANGELOG.rst LICENSE > LICENSE.pbs README.rst examples setup.cfg src > tox.ini > > There are 3 separate features of the source here being ignored; docs, > examples and tests. This is a minimal ebuild and therefore denying yourself > and any user of the opportunity and the choice of reading the docs (provided > in the source), perusing and trying the exe python script file > gst-player.py, and finally the testsuite is ignored. Testsuites are > written by authors for a purpose. Try the attached patch. It installs the docs and runs the tests. I don't know what to do with the gst-player.py file. It's useless, no one needs it. I don't even know why it's there. > Also, the only stabled version was entered > > *livestreamer-1.7.2 (29 Dec 2013) > > and there are 7 more piled up since then. That was bug 538308, which I will reopen once the last dep has gone stable (bug 544994).
Also, delete these from portage: 1.7.5, 1.8.0, 1.8.1, 1.8.2, 1.10.2
01 Apr 2015; Ian Delaney <idella4@gentoo.org> -livestreamer-1.10.2.ebuild, -livestreamer-1.7.5.ebuild, -livestreamer-1.8.0.ebuild, -livestreamer-1.8.1.ebuild, -livestreamer-1.8.2.ebuild: rm old 1. The test phase you added works out of the box. That's fine 2. +DOCS=( is NOT what I meant. The var DOCS is ambiguous in portage in gentoo. I meant these ones; livestreamer-1.12.1/docs which when built go here; image/usr/share/doc/livestreamer-1.12.1/html/ api_guide.html changelog.html genindex.html install.html players.html search.html _static api.html cli.html index.html issues.html plugin_matrix.html searchindex.js twitch_oauth.html Seeing you didn't even know, for your edification, here is the code to add to the ebuild; python_compile_all() { use doc && emake -C docs html } python_install_all() { use doc && local HTML_DOCS=( docs/_build/html/. ) distutils-r1_python_install_all } You will find this repeated in dozens of python packages under dev-python. 3. The examples are similar. work/livestreamer-1.12.1/examples/gst-player.py This you will note is a script file, an executable. Once installed, the user can run it by calling it directly or as a module to python. It offers an example of the functionality of the package net-misc/livestreamer. It also goes in image/usr/share/doc/. Examples are an option and not an essential file to install. I think we can do without insisting on adding this example script file. There are also dozens of ebuilds in portage that illustrate the addition of examples in python packages. Add the above code to your local ebuild, remake a patch to suit and I can bump it.
Take it as-is, or leave it.
Created attachment 400332 [details] ebuild with docs, flag and deps Out of necessity, I made an ebuild for the 1.12.1 version in a local overlay following Ian Delaney's recommendations. I'm now attaching it here in the hopes that it will move things along faster. Please double-check that I didn't make any mistakes as I don't have any experience in making ebuilds.
(In reply to Nikos Chantziaras from comment #6) > Take it as-is, or leave it. left, by me, however there are others in the project who may commit it on yr behalf. It just doesn't have to be me. The point is that both forms offered by you pass minimal requirements. They also miss options that are in this package both common and easy to add. The DOCS= added in the patch happens to compete with the distutils-r1 which installs those DOCS by default internally. (In reply to the.telvanni from comment #7) > I'm now attaching it here in the > hopes that it will move things along faster. > > Please double-check that I didn't make any mistakes as I don't have any > experience in making ebuilds. Well it seems you started a little. The ebuild now needs a test use flag, IUSE="doc test" reason; most testsuites use / require the RDEPs, so it needs a use flag test to list / demand the DEPs in the deps like so; DEPEND="dev-python/setuptools[${PYTHON_USEDEP}] test? ( ${RDEPEND} ) doc? ( dev-python/sphinx[${PYTHON_USEDEP}] )" You'll find many instances of this under dev-python. I'll stop there. Now since we have an impasse, the addition of the bump of this packages requires a final opinion from a higher authority in this project, which is unfortunate since it counters the hope for the previous contributor to move things along faster. All I can say is for now you can emerge the bumped version from your own overlay into your system, with docs, rather than DOCS. Also if you'd like to learn more ebuild writing, just say so. I do alot of that.
Created attachment 401270 [details] livestreamer-1.12.1.ebuild Another proposed ebuild for livestreamer-1.12.1. Changes from ebuild by the.telvanni@gmail.com: - python_test() is fixed to call the proper command (as in patch by Nikoli) - DOCS is populated with Changelog and README, which makes sense IMHO - 'test' USE is introduced Tested and works on my amd64 machine (python{2_7,3_3}). With python-3.3 there is an exception after the tests related to the concurrent.futures module, though. Testsuite itself completes OK.
(In reply to Coacher from comment #9) > Created attachment 401270 [details] > livestreamer-1.12.1.ebuild > > Another proposed ebuild for livestreamer-1.12.1. > > Changes from ebuild by the.telvanni@gmail.com: > > - python_test() is fixed to call the proper command (as in patch by Nikoli) > - DOCS is populated with Changelog and README, which makes sense IMHO without the DOCS=( CHANGELOG.rst README.rst ) ~/cvsPortage/gentoo-x86/net-misc/livestreamer $ ebuild livestreamer-1.12.1.ebuild clean install * python2_7: running distutils-r1_run_phase python_install_all >>> Completed installing livestreamer-1.12.1 into /mnt/gen2/TmpDir/portage/net-misc/livestreamer-1.12.1/image/ $ ls /mnt/gen2/TmpDir/portage/net-misc/livestreamer-1.12.1/image//usr/share/doc/livestreamer-1.12.1/ README.rst.bz2 What occurs here is the default install be the eclass installs README.rst and compresses it. With the DOCS set, it merely adds CHANGELOG.rst. On my part I don't think users normally go looking for a CHANGELOG and I would therefore leave out DOCS var all together. It's not wrong, but imo it's installing an unneeded file and just takes up space. ditto the presence of the DOCS var. (Less is more) > - 'test' USE is introduced > This is tricky. In this ebuild its addition is wrong because it is never actually used. To use it, do like so; DEPEND="dev-python/setuptools[${PYTHON_USEDEP}] test? ( ${RDEPEND} ) So imo DEPEND="${RDEPEND} is actually wrong but not broken. To demo, - unmerge say requests and run $ ebuild livestreamer-1.12.1.ebuild clean install - See it installs - re-run $ ebuild livestreamer-1.12.1.ebuild clean test and it will promptly start d'loading requests. This proves that RDEPEND deps are NOT required in DEPEND but ARE required to run tests. A broken ebuild either causes repoman to error, or has errors that will trigger a fail of some type. DEPEND="${RDEPEND} merely causes the RDEPs to be passengers in DEPEND without hurting the merge flow. The above is what I use. > Tested and works on my amd64 machine (python{2_7,3_3}). With python-3.3 > there is an exception after the tests related to the concurrent.futures > module, though. Testsuite itself completes OK. Well done. Now it is time to ask who would like to be nominated substitute proxy maintainer. I am spoilt for choice; TWO candidates. Both is a viable state.
I hereby remove myself as proxy maintainer for this package. Have a nice day.
Created attachment 401372 [details] livesteramer-1.12.1.ebuild (In reply to Ian Delaney from comment #10) > What occurs here is the default install be the eclass installs README.rst > and compresses it. With the DOCS set, it merely adds CHANGELOG.rst. On my > part I don't think users normally go looking for a CHANGELOG and I would > therefore leave out DOCS var all together. It's not wrong, but imo it's > installing an unneeded file and just takes up space. ditto the presence of > the DOCS var. (Less is more) I agree that many users usually ignore the changelog shipped with a package, but in the case where something goes 'unusual' changelog can be a nice addition and helps to narrow down the problem. If the problematic change is in the changelog user does not have to guess whether this is a program itself that is misbehaving or external dep or lib. I'd prefer to keep the changelog (i.e. DOCS is left unchanged), but the final decision is up to you. > This is tricky. In this ebuild its addition is wrong because it is never > actually used. To use it, do like so; > > DEPEND="dev-python/setuptools[${PYTHON_USEDEP}] > test? ( ${RDEPEND} ) Done. > Well done. Now it is time to ask who would like to be nominated substitute > proxy maintainer. I am spoilt for choice; TWO candidates. Both is a viable > state. Sorry, cannot do proxy maintaining on this one. Unfortunately Nikos also resigned from maintaining leaving the package in a dangling state. From my point of view I am just looking at livestreamer for the first time and I don't plan to use it somewhat often, so I am not really a viable candidate for maintaining this one as I am not a regular user.
Coacher(In reply to Coacher from comment #12) > Created attachment 401372 [details] > livesteramer-1.12.1.ebuild > > I agree that many users usually ignore the changelog shipped with a package, > but in the case where something goes 'unusual' changelog can be a nice > addition and helps to narrow down the problem. I'd prefer to keep the > changelog (i.e. DOCS is left unchanged), but the final decision is up to you. > I am quite prepared to retain DOCS=( CHANGELOG.rst README.rst ). It is valid. > Sorry, cannot do proxy maintaining on this one. That's fine, one remaining candidate. I can commit this in a flash, but the purpose is to support users to proxy maintain. To edit to orphaned packages is a last resort.
As a new version of this program has been released (1.12.2) and it is now without any maintainers, I'd like to come forward and volunteer my time to be a proxy maintainer. I'm very new to this but I'd rather not have this package fall out of the portage tree.
(In reply to DKay from comment #14) > As a new version of this program has been released (1.12.2) and it is now > without any maintainers, I'd like to come forward and volunteer my time to > be a proxy maintainer. I'm very new to this but I'd rather not have this > package fall out of the portage tree. Ah good I had not checked this until now. Being very new is no obstacle, everyone has to be very new at the start. The ebuild is all but done for the -1.12.1, however for now, your email is a mile long. Do you really wish to utilise andcycle-gentoo.bugs@andcycle.idv.tw or do you have another more succinct email address? Next step is to put your name and email addy in metadata.xml but I am not sure it will fit. This package is quite an easy one. It is neither taxing nor time consuming. Await your reply.
My email should be the.telvanni@gmail.com. I googled the other email you provided and it seems to be another unrelated user on the gentoo bugzilla. Perhaps there was a mix-up?
(In reply to DKay from comment #16) > My email should be the.telvanni@gmail.com. I googled the other email you > provided and it seems to be another unrelated user on the gentoo bugzilla. > Perhaps there was a mix-up? Oh that was the reporter, (me getting muddled). I have set you as (new) proxy maintainer however I have entered your name for now as Dkay, I will need full name. If, like others have been lately, you are shy about it you can email it to me, however metadata.xml in portage and here in bugzilla are both in full public view. Any diff between the 2 in my view is purely a personal one. For now I have bumped it to 1.12.1 with how (the standard) I consider it should be. You can now submit a whole ebuild or a unified diff patch in the usual way and the 1.12.2 'ack'ing you as proxy maintainer. *livestreamer-1.11.1 (24 Dec 2014) is good for submission for stable request, else it can be skipped in favour of the freshly bumped -1.12.1 after awaiting the required time. *livestreamer-1.12.1 (09 May 2015) 09 May 2015; Ian Delaney <idella4@gentoo.org> +livestreamer-1.12.1.ebuild, metadata.xml: bump; set new maintainer under proxy-maintainers herd wrt 542894
I changed my username on bugzilla to my real name: Guillaume Lespinasse I filed a bug to bump version 1.12.2 and will file a stable request for 1.12.1 in a week if no issues arise (too soon?)
1.12.1 and 1.12.2 are in tree for a while. Can this one be closed?
