In http://bugs.gentoo.org/show_bug.cgi?id=150091 dacook provided a sufficient response for the uninformed/non-substantive bug to be closed (there was no evidence that the ebuild failed, or that the package was installed in non-working form, or that even one gentoo admin was in panic), or a _substantive_ response, not for the unsupported action to proceed. This is an effective ebuild installable _as is_. If an administrator/installer is serious-enough to want further services, such as keyed binaries, stealth, and extensive file configurations, they should be able to figure out how to set KEY_FPR and EXTRA_ECONF in /etc/portage/env. To not recognize that is to discount the very core of the tools that support the usefulness of the gentoo package tree. Sure, a better package _could_ be written. And that language improved (the thrust of the message is important for inattentive installers to understand). But there are few ebuilds, even among core, that would survive such a test. Restore to tree. Reproducible: Always Steps to Reproduce: emerge samhain Actual Results: emerge: there are no ebuilds to satisfy "app-forensics/samhain" Expected Results: Calculating dependencies ...
maintainer-wanted, like bug 321253 Feel free to take it to the sunrise overlay, as multiple people suggested on the -dev mailing list. http://archives.gentoo.org/gentoo-dev/msg_67f31d06d4747a011643714fcac07f22.xml *** This bug has been marked as a duplicate of bug 321253 ***
No, this is not a duplicate of bug http://bugs.gentoo.org/show_bug.cgi?id=324013. Specifically, this bug, bug 324013 reports that the ebuild worked fine. Bug 324013 is missing details, which I've asked for. The separate topic is the logic for shifting to sunrise. There was no confirmed bug to address, therefore the move didn't qualify on that grounds. Which would also moot those ground for "maintainer-wanted". That leaves for a justification only "permanently keyworded". But how does it serve users to remove a testing package that's still in testing yet has no confirmed bugs? For users wishing to go ~arch it's working fine. Now, for those very same users, it has to go in overlay. Blah. It is an entirely different case, and helpful to users, when an arch package goes ~arch. And, btw, even if a maintainer had stepped fwd and satisfied the nonsense editorial, the package would still be ~arch for quite a while, since, obviously, there'd been no effort in the herd to complete the testing (or even to see if the ebuild comment impacted the build). It's just a mistake to remove it; just put it back in the tree. You may have to remove it later ... but on sufficient grounds.
