Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 341731 - Please add net-misc/arm (Tor text status monitor) to Portage
Summary: Please add net-misc/arm (Tor text status monitor) to Portage
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Christian Faulhammer (RETIRED)
URL: http://www.atagar.com/arm/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-19 07:36 UTC by Jesse Adelman
Modified: 2010-12-03 08:44 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
net-misc/arm-1.4.0.ebuild (arm-1.4.0.ebuild,721 bytes, text/plain)
2010-12-02 08:17 UTC, Jesse Adelman
Details
net-misc/arm/arm-1.4.0.ebuild (arm-1.4.0.ebuild,869 bytes, text/plain)
2010-12-03 02:30 UTC, Jesse Adelman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Adelman 2010-10-19 07:36:42 UTC
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"
Comment 1 Christian Faulhammer (RETIRED) gentoo-dev 2010-10-25 06:28:49 UTC
Jesse, do you have any ebuild available?  If so, I would be willing to proxy you as maintainer.
Comment 2 Jesse Adelman 2010-10-25 06:42:14 UTC
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.
Comment 3 Christian Faulhammer (RETIRED) gentoo-dev 2010-10-25 08:14:02 UTC
(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.
Comment 4 Jesse Adelman 2010-12-02 08:17:44 UTC
Created attachment 256113 [details]
net-misc/arm-1.4.0.ebuild

Please be kind, Gentoo QA. :)
Comment 5 Jesse Adelman 2010-12-02 08:18:47 UTC
Christian, thanks for proxy-maintaining this. I'm open to constructive criticism and will post corrections, if needed (likely ;) ). Cheers!
Comment 6 Christian Faulhammer (RETIRED) gentoo-dev 2010-12-02 10:48:39 UTC
(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.
Comment 7 Jesse Adelman 2010-12-02 11:07:35 UTC
(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. :)
Comment 8 Jesse Adelman 2010-12-03 02:29:09 UTC
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.
Comment 9 Jesse Adelman 2010-12-03 02:30:53 UTC
Created attachment 256207 [details]
net-misc/arm/arm-1.4.0.ebuild
Comment 10 Christian Faulhammer (RETIRED) gentoo-dev 2010-12-03 08:44:09 UTC
(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.