| Summary: | Please add net-misc/arm (Tor text status monitor) to Portage | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jesse Adelman <jesse> |
| Component: | New packages | Assignee: | Christian Faulhammer (RETIRED) <fauli> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | atagar1 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.atagar.com/arm/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
net-misc/arm-1.4.0.ebuild
net-misc/arm/arm-1.4.0.ebuild |
||
Jesse, do you have any ebuild available? If so, I would be willing to proxy you as maintainer. Ah, I'll start whipping one up early this week. Thanks! I've been working with the upstream developer via IRC to help him/her QA stuff and add features, so that might be cool. (In reply to comment #2) > Ah, I'll start whipping one up early this week. Thanks! I've been working with > the upstream developer via IRC to help him/her QA stuff and add features, so > that might be cool. If you want extended feedback and/or help you can ask in the IRC channel #gentoo-sunrise, they regularly review ebuilds. Alternatively or if you are finished you can attach the ebuild here and I will review it. Created attachment 256113 [details]
net-misc/arm-1.4.0.ebuild
Please be kind, Gentoo QA. :)
Christian, thanks for proxy-maintaining this. I'm open to constructive criticism and will post corrections, if needed (likely ;) ). Cheers! (In reply to comment #4) > Created an attachment (id=256113) [details] > net-misc/arm-1.4.0.ebuild > > Please be kind, Gentoo QA. :) We'll do it slowly, won't hurt. :) Thank you very much for the contribution. > DESCRIPTION="The anonymizing relay monitor (arm) is a terminal status monitor > for Tor relays" Just a suggestion. Remove the "(arm)" and "The", but capitalize the name. > MY_P=${P}"-2" Define it just after inherit...style issue. But as it is used only once, you can leave it out for now and use ${P}-2 in the SRC_URI. > KEYWORDS="~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~x86-macos" Have you tested it on all these arches? > DEPEND=">=dev-lang/python-2.5 [...] > dev-lang/python[ncurses]" Ok, this is tricky. Those dependencies are done with the python.eclass and quite complicated. There is a guide at http://www.gentoo.org/proj/en/Python/developersguide.xml You have the option to read it and set the needed variables before inherit, or I can do it for you. The setup is needed to distinguish build phases for several versions of Python installed in parallel (3.x and 2.x here). > src_prepare() { > mv ${WORKDIR}/arm ${WORKDIR}/arm-new > mv ${WORKDIR}/arm-new/* ${WORKDIR}/ > rmdir ${WORKDIR}/arm-new > } Important actions should be followed by an "|| die" to abort the build if they fail and most variables containing a path need to be surrounded by quotes, so spaces won't break the path expansion. Apart from that...I don't get your moving around. This can be reduced to mv ${WORKDIR}/arm/* ${WORKDIR}/ rmdir ${WORKDIR}/arm But redefining "${S}" is even less pain. Most src_*() functions enter the directory "${S}" which is defined as ${WORKDIR}/${PN}-${PV} by default. A line S=${WORKDIR}/${PN} is sufficient here (not tested). You abused the fallback for ${S}, if there is no subdirectory under ${WORKDIR}. > src_install() { > distutils_src_install > } Every eclass tells Portage which standard functions (src_prepare, src_install pkg_setup etc.) it overrides, the last one is then automatically loaded as the src_install() phase. Say you have "inherit elisp distutils", then both have a src_install() function (elisp_src_install() and distutils_src_install()). As distutils gets loaded last, it substitutes the default definition (if any). Thus no need to define src_install() at all in the ebuild. (In reply to comment #6) > (In reply to comment #4) > > Created an attachment (id=256113) [details] [details] > > net-misc/arm-1.4.0.ebuild > > > > Please be kind, Gentoo QA. :) > > We'll do it slowly, won't hurt. :) Thank you very much for the contribution. > > > > DESCRIPTION="The anonymizing relay monitor (arm) is a terminal status monitor > for Tor relays" > > Just a suggestion. Remove the "(arm)" and "The", but capitalize the name. > > > MY_P=${P}"-2" > > Define it just after inherit...style issue. But as it is used only once, you > can leave it out for now and use ${P}-2 in the SRC_URI. > > > KEYWORDS="~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~x86-macos" > > Have you tested it on all these arches? > > > DEPEND=">=dev-lang/python-2.5 > [...] > > dev-lang/python[ncurses]" > > Ok, this is tricky. Those dependencies are done with the python.eclass and > quite complicated. There is a guide at > http://www.gentoo.org/proj/en/Python/developersguide.xml You have the option > to read it and set the needed variables before inherit, or I can do it for you. > The setup is needed to distinguish build phases for several versions of Python > installed in parallel (3.x and 2.x here). > > > src_prepare() { > > mv ${WORKDIR}/arm ${WORKDIR}/arm-new > > mv ${WORKDIR}/arm-new/* ${WORKDIR}/ > > rmdir ${WORKDIR}/arm-new > > } > > Important actions should be followed by an "|| die" to abort the build if they > fail and most variables containing a path need to be surrounded by quotes, so > spaces won't break the path expansion. Apart from that...I don't get your > moving around. This can be reduced to > mv ${WORKDIR}/arm/* ${WORKDIR}/ > rmdir ${WORKDIR}/arm > But redefining "${S}" is even less pain. Most src_*() functions enter the > directory "${S}" which is defined as ${WORKDIR}/${PN}-${PV} by default. A line > S=${WORKDIR}/${PN} > is sufficient here (not tested). You abused the fallback for ${S}, if there is > no subdirectory under ${WORKDIR}. > > > src_install() { > > distutils_src_install > > } > > Every eclass tells Portage which standard functions (src_prepare, src_install > pkg_setup etc.) it overrides, the last one is then automatically loaded as the > src_install() phase. Say you have "inherit elisp distutils", then both have a > src_install() function (elisp_src_install() and distutils_src_install()). As > distutils gets loaded last, it substitutes the default definition (if any). > Thus no need to define src_install() at all in the ebuild. > I will address the other points soon (past bedtime), but I want to address the src_prepare stuffs. I should have mentioned that I tried your solution first. However, there's a sneaky arm file under the arm/ subdirectory here (${WORKDIR}/arm/arm) which, when mv'd in the manner you suggest, fails, when it tries to overwrite a directory with a file. Hence, I did some extra moving around. Thanks for the feedback. I'll address the changes you suggest tomorrow. :) Howdy. OK, I believe I've addressed your suggestions and help. I'm uploading a corrected ebuild now, with additional elog info and a tip. floppym and marienz in #gentoo-dev-help helped me work out an issue I had with S=, where it was silently failing back when I used ${P} vs. ${PN} in the assignment.
Created attachment 256207 [details]
net-misc/arm/arm-1.4.0.ebuild
(In reply to comment #8) > Howdy. OK, I believe I've addressed your suggestions and help. I'm uploading a > corrected ebuild now, with additional elog info and a tip. floppym and marienz > in #gentoo-dev-help helped me work out an issue I had with S=, where it was > silently failing back when I used ${P} vs. ${PN} in the assignment. Which is the default value...:) and expands to ${WORKDIR}/${PN}-${PV}. Anyway, I am satisfied with the ebuild and just committed it to the Portage tree. If you want anything changed, file a bug report (put me in cc if bug wranglers take time to assign it). First action now is that you file a KEYWORDREQ for the amd64 keyword, see bug 308715 for an example. You will get cced on all bugs file, fix them by attaching patches to that bug so it is properly kept track in public. After 60 days without any filed bugs we can request a stabilisation on x86/amd64, usually a new stabilisation is due after 30 days, but a brand-new package can use some more testing. |
Thanks! "The anonymizing relay monitor (arm) is a terminal status monitor for Tor relays, intended for command-line aficionados, ssh connections, and anyone stuck with a tty terminal. This works much like top does for system usage, providing real time statistics for: * bandwidth, cpu, and memory usage * relay's current configuration * logged events * connection details (ip, hostname, fingerprint, and consensus data) * ... etc"