Hi, this a ebuild for the high-performance bittorrent tracker opentracker using libowfat and dietlibc. The problem is, that they had no proper release yet, so this is using current cvs. dev-libs/libowfat needs to be bumped to 0.27 (well, at least to a newer version than the one in the tree). Reproducible: Always Steps to Reproduce:
Created attachment 147404 [details] opentracker-9999.ebuild
libowfat 0.28 is in the tree and if it's compiled with -fomit-frame-pointer (see #262663) opentracker appears to works well (on amd64) (but more testing is needed though). I modified the ebuild : - correct typo (FEATUES_INTERNAL -> FEATURES_INTERNAL) - add ipv6 feature and useflag - add debug feature and useflag - add blacklist and whitelist features and useflags (exclusives) Tested with amd64 and ipv4. New ebuild attached below. (this bug maybe should be marked as "depends on #262663" ?)
Created attachment 185189 [details] new opentracker ebuild with more use flags handled
Created attachment 186132 [details] opentracker cvs ebuild Handle : - statistics access restriction, - syncing - request logging - gzip compression - better use of the debug useflag - installs the sample configuration file in the doc dir.
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 282341 [details] Improved version
Created attachment 282343 [details] opentracker.conf.d conf file to place to files sub-directory
Created attachment 282345 [details] opentracker.init.d init.d file to place to files sub-directory
I added following goodies: -init.d autostart script -configuration file is placed in /etc
Created attachment 282361 [details] ebuild partly merged thanks ! the ebuild was a bit updated since 2009 (http://gitorious.org/drzraf/gentoo/blobs/master/net-p2p/opentracker/opentracker-9999.ebuild) I merged your changes in this attachment but I think there is a place for debate about (pre-)installing the configuration file. Opentracker needs care (most of the options are setup at build-time). It seems assumed that people compiled it themselves, can read/change and understand their configuration. I would rather see a simple elog() line in pkg_postinst() like: "A sample configuration file can be found under /usr/share/doc/opentracker-9999" In the init script I changed: - ${EXEC_PARAMS} which should be left unquoted - I removed the $CONFFILE variable (redundant with EXEC_PARAMS, one should be chosen over the other) - Copyright set to 2011 In the ebuild current shape: - advises are needed about handling portage debug features (splitdebug, nostrip) - default use-flags settings should be defined - + I would really like to get rid of all these calls to sed :)
Hi, anyone willing to write a snapshot ebuild?
Created attachment 342556 [details] opentracker-9999.ebuild This ebuild differs from older ones in such things: 1. Upstream changed from cvs.erdgeist.org to https://github.com/flygoast/opentracker. GitHub repo has complete code from cvs + two useful features (live sync through unicast and persistent storage on disk), and some minor fixes. 2. Network logging (USE-flag log-network) is disabled, because upstream doesn't support it currently. Error from source code: "Live logging networks disabled at the moment". 3. REQUIRED_USE is introduced. 4. More fixes for compiler flags. 5. Introduced all possible USE-flags, except USE-flag for switch DWANT_DEV_RANDOM, because srandomdev() doesn't exist on linux. 6. All QA fixed. 7. Init script was rewritten and now supports multiple instances. > advises are needed about handling portage debug features (splitdebug, nostrip) splitdebug and nostrip handling is out of scope this or any other ebuild. Ebuild should only provide a possibility to get a debug symbols. > default use-flags settings should be defined fullscrapes and gzip. First one - because it's enabled by default in the standard. Second one - less traffic is almost always good.
Created attachment 342560 [details] man, init-script for ebuild
Created attachment 342562 [details] metadata for ebuild I would like to be a proxy-maintainer for this ebuild.
notice: http://erdgeist.org/arts/software/opentracker/ makes no mention of github. Github repository states itself to be an "Unofficial fork of opentracker".
(In reply to comment #14) > I would like to be a proxy-maintainer for this ebuild. Good, CCing proxy maintainers...
The HOMEPAGE and SRC_URI are from different authors, could this be changed to match? Is it possible to use their CVS instead?
It is better to set HOMEPAGE to https://github.com/flygoast/opentracker, since git has an improved code with more features. Also code in git was updated 3 months ago, and cvs's code was not updated more then a 9 months. I left HOMEPAGE as it was, because it is pointed to the original author homepage and there are more information about opentracker on it. > Is it possible to use their CVS instead? It doesn't make big sense. In the beginning I used code from cvs with patch, made from code in git. But patch was too big, I got QA "file size" for it. I split it into two patches, one with live sync through unicast feature and second with persistence feature. But patch was still too big. Then I realized, that I had to create a series of patches to resolve QA connected with patch size. I decided to go another way, and switched to git. If someone needs original code from cvs, USE-flags persistence and live_sync_unicast should not be used. This probably should be mentioned in pkg_postinstall. It's trivial to get 'almost' original cvs code from git, and hard to provide more features with cvs code. I wrote an email to opentracker's author about project status, and didn't receive any response. So project status is unknown. That is other reason why to use a git code.
Just came across this in my mail again, let's see... (In reply to comment #18) > It is better to set HOMEPAGE to https://github.com/flygoast/opentracker, > since git has an improved code with more features. Also code in git was > updated 3 months ago, and cvs's code was not updated more then a 9 months. > I left HOMEPAGE as it was, because it is pointed to the original author > homepage and there are more information about opentracker on it. Multiple URLs can be listed there, I'd suggest to first list the github (because that is where the code originates from) and then list the original page (as it has more information); that way, the user has access to both. For all the use flag conditional code in the src_prepare function, I wonder if we can somehow enumerate them to clean up the ebuild; perhaps you can just strip all ^#?FEATURES.*$ lines instead and then just write a simple usex-based loop or so, search "usex" on http://devmanual.gentoo.org/ebuild-writing/eapi/ for more information. If needed, we can run this through #gentoo-dev-help / #gentoo-sunrise. Anyhow, this approach is hacky and is the result of the upstream maintainer not providing a more proper configure approach; so filing a bug upstream to request that may also be helpful towards other people in the future. As far as I can see, it looks good for the rest; didn't do a test build yet for missing dependencies and testing, will do that later. If we can get these last changes in I think we can add this to the Portage tree.
Created attachment 347442 [details] updated ebuild Added github URL as the first URL to HOMEPAGE. All FEATURES is commented now before any further actions. Introduced usex-based loop through FEATURES. > so filing a bug upstream to request that may also be helpful towards other people in the future. I got a reply to my letter from opentracker's author. He will not add the persistence feature to original sources, because of promise given to PirateBay users. What about a live sync through unicast feature. He said he would think. I also asked him to make a tarball, but still there is no anyone on the original site. So I don't think there will be some changes to the build system of opentracker, and we can add this to Portage the way it is now.
Created attachment 347510 [details] ebuild "Fix compilation issue without use of persistence flag" moved to upstream (github)
Without upstream willing to cooperate maintenance becomes much more problematic; for instance, releases can easily be done by tagging (https://github.com/flygoast/opentracker/releases) and all the flags can easily be covered with configuration from autotools which can also be used to get rid of most of the Makefile patching we unnecessarily need to do. (In reply to Tom Wijsman (TomWij) from comment #19) > Anyhow, this approach is hacky and is the result of the upstream maintainer > not providing a more proper configure approach; so filing a bug upstream to > request that may also be helpful towards other people in the future. So, please ask for this if you can, it would raise its quality.
Created attachment 357184 [details] opentracker-0.1.ebuild > So, please ask for this if you can, it would raise its quality. Upstream (github) had created release, I attached a corresponding ebuild (opentracker-0.1.ebuild).
Created attachment 374464 [details] ebuild for opentracker-0.5
Created attachment 374466 [details] updated ebuild 1. Added USE-flag httpdebug. 2. Added epatch_user. 3. Now uses user eclass.
please note that "real" upstream now provides a git repository too. I still don't see the point to make an ebuild which does not fetch the official upstream. At least tracking the so-much-needed-patches integration into *real* upstream would make sense.
