Created attachment 421018 [details] My ebuild for 1.16.0 The version in portage is very old. There are newer versions, the newest one from 07.12.2015. In my local overlay I use the newest one which works great (I use it as standard editor). As an attachment I added my actual ebuild. (The ebuild is a modification of portage's one. Could be that the only thing I changed is its name. Not sure about this.) The versions available can be found here: http://lav.yar.ru/download/le/ Best regards
Hello, This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org or join #gentoo-proxy-maint on Freenode IRC. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers
Hi Gerold; As I mentioned in my E-Mail there are a couple of minor issues with this ebuild. The first (which would be identified by running `repoman` from the ebuild directory) is that the header needs to be updated (see ${PORTDIR}/header.txt) [0]. Second is that, being a version bump, KEYWORDS needs to be dropped to ~arch ("~amd64 ~ppc ~x86"). [1] Third, as there are no USE flags for the package, IUSE does not need to be defined and can be removed entirely (though this is something of a stylistic choice as defining it as empty does no harm, but it does reduce the size of the ebuild by one line). [2] Otherwise, this ebuild looks fine to me, and builds and installs fine in my testing. Once the above are resolved, a developer will come along and offer any further tips on the ebuild that I missed and, once they're happy with it, will organise getting it committed and having you added as proxy-maintainer if you're still interested. [0]: https://devmanual.gentoo.org/ebuild-writing/file-format/index.html [1]: https://devmanual.gentoo.org/keywording/index.html [2]: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#iuse
Created attachment 423856 [details] ebuild for le-1.16.1
Made a new ebuild (new le-version is out) and incorporated your suggestions. Additionally I removed the version information on ncurses in RDEPEND, because all versions available in portage are ok. And I changed the licence from GPL-2 to GPL-3, because the self-info of le in the actual version (1.16.1) states this. Two questions remain for me: 1) What about the metadata? 2) Is it generally possible to stabilize this package and if how does it work? Best regards
(In reply to Gerold Schellstede from comment #4) > Made a new ebuild (new le-version is out) and incorporated your suggestions. I notice that you also added "~arm" to KEYWORDS. This should only be done if you have an arm-based platform and can verify that it works, to some degree, on that platform (even if upstream claim support). If you don't have an arm device, then you should file a KEYWORDREQ bug for the package. This process is probably better described by a developer. > Additionally I removed the version information on ncurses in RDEPEND, > because all versions available in portage are ok. And I changed the licence > from GPL-2 to GPL-3, because the self-info of le in the actual version > (1.16.1) states this. These are fine - so long as dependencies can be met and licensing information is accurate. > Two questions remain for me: > > 1) What about the metadata? You can attach a modified metadata.xml file here, though developers sometimes make this change on-the-fly if one isn't available. > 2) Is it generally possible to stabilise this package and if how does it > work? Generally, yes - there are some requirements for stabilisation that need to be met (described on the KEYWORDS page in the devmanual that I linked previously, and also on the Wiki). In brief, a given version should be in-tree and have no significant bugs open for ~30 days and all dependencies should have a stable version on the target platform(s). When ready, a STABLEREQ bug can be filed and arch projects CC'd to perform the stabilisation. This should be coordinated with the developers from the Proxy-Maintainers project when you're ready to begin the stabilisation process. In the meantime, you might want to have a quick look through the devmanual in general to familiarise yourself with how things work. :) Cheers!
Thanks for your hints. > I notice that you also added "~arm" to KEYWORDS. This should only be done if > you have an arm-based platform and can verify that it works, to some degree, > on that platform (even if upstream claim support). > > If you don't have an arm device, then you should file a KEYWORDREQ bug for > the package. This process is probably better described by a developer. I do not know if arm is officially support by the developer of le, but I installed it on my raspberry and it works very well so I thought this would be a good idea ;-) Regards
(In reply to Gerold Schellstede from comment #6) > Thanks for your hints. I'm happy to help. I've gone over this ebuild with a developer and we have found a couple of further issues that I missed previously. EAPI should be defined in the ebuild (see examples from other ebuilds). If not defined, then EAPI defaults to 0 (which has long been deprecated). Currently EAPI=6 is the latest though EAPI=5 is still in use and not deprecated [0,1]. The dependency on sys-libs/ncurses should define which SLOT it depends on as there are multiple available [2]. This is also a function of the EAPI in use as EAPI=0 does not support SLOTed dependencies. In this case I believe SLOT=0 for ncurses is what you need - for example: RDEPEND="sys-libs/ncurses:0=" `die` is not required in src_install() as from EAPI=4 all internal ebuild helpers (such as `emake`) automatically die on failure [3]. > > I notice that you also added "~arm" to KEYWORDS. This should only be done if > > you have an arm-based platform and can verify that it works, to some degree, > > on that platform (even if upstream claim support). > > > > If you don't have an arm device, then you should file a KEYWORDREQ bug for > > the package. This process is probably better described by a developer. > > I do not know if arm is officially support by the developer of le, but I > installed it on my raspberry and it works very well so I thought this would > be a good idea ;-) I'm still not certain about adding this to KEYWORDS given that upstream do not support it. To be clear, if users wish to install it on non-keyworded arches they can unmask it locally, so not keywording it doesn't mean it's impossible to install; but keywording it does imply that it is supported and at least generally working. I would check with upstream about whether support for arm is viable or if it's excluded for a reason; and possibly with a developer if you do want to add it. At the least, the ebuild could be committed without arm and, once clarified, a KEYWORDREQ bug filed to add arm to KEYWORDS later. Lastly, just to double-check: you are still happy to proxy-maintain this package? Your name and email as they appear here will be added to the metadata on commit. Cheers! [0]: https://devmanual.gentoo.org/ebuild-writing/eapi/index.html [1]: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-176000E [2]: https://devmanual.gentoo.org/general-concepts/dependencies/index.html [3]: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-13100011.3.3.1
Created attachment 424302 [details] Updated ebuild
Updated the ebuild and introduced the EAPI things you mentioned. However, I deleted the ~ppc and ~arm keywords, because I cannot test ppc at all and arm doesn't seem to be officially supported. And I am still happy ;-)
Okay, one last point: (In reply to Gerold Schellstede from comment #9) > However, I deleted the ~ppc and ~arm keywords, because I cannot test ppc at > all and arm doesn't seem to be officially supported. Removing ~arm from KEYWORDS is fine, however ~ppc should be kept since the previous version does support it - "When upgrading, drop all existing keywords from arch to ~arch, and leave any existing ~arch keywords intact" [0]. Because the package already had ppc in KEYWORDS it should be retained even though you don't have ppc hardware to test on because it's supported upstream and known to have worked previously. Otherwise, my buildtests passed without issue and the program works fine, so I don't see anything else beyond the KEYWORDS that needs to be done. Also, as an aside, when attaching a file to a bug you can mark previous versions of the file that you've attached as obsolete in order to make it clear which one is the current incarnation. ;)
Forgot to add reference :D [0]: https://devmanual.gentoo.org/keywording/
This has now been committed (note that Amy added the "ppc" keyword back in). commit c069d1be993286a90abb58840b152fffdf73c759 Author: Amy Winston <amynka@gentoo.org> Date: Mon Feb 1 13:02:10 2016 +0100 app-editors/le: 1.16.1 version bump bug #570008 commit 48e8e1a82cdb99a99f99056fe34df6b68a727099 Author: Amy Winston <amynka@gentoo.org> Date: Mon Feb 1 12:56:26 2016 +0100 app-editors/le: add proxy-maintainer commit 9f1383b316da1dc447380e0e98880273a2be8a34 Author: Amy Winston <amynka@gentoo.org> Date: Mon Feb 1 12:54:25 2016 +0100 app-editors/le: eapi bump Again, thanks for stepping up and taking maintainership of this! Closing bug per request from Amynka.
