On 1/25/20 12:32 PM, gentoo-user+ow...@lists.gentoo.org wrote:
Some messages to you could not be delivered. If you're seeing this
message it means things are back to normal, and it's merely for your
information.
Here is the list of the bounced messages:
- 189317
Getting these messages again. They 'had disappeared for a while...'
Verizon mail server system is aweful, so I'm still working on a
permanent solution. Anyway
subject:: maintainer-needed tools?
So,
https://qa-reports.gentoo.org/output/maintainer-needed.html
and
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#Proxied_Maintainer_gets
I use lots of these old packages, on old installs, and with minimal
(some embedded) devices. So I feel like I should help maintain some of
them; especially the ones I use. Many have (3 zeros) Open bugs:: for
R-revdeps, D-revdep and P-revdeps. So here are some questions/requests
for tools or useful scripts that provided some extended functionality.
1. Is there a 'tool/script' that searches (matches) this need-matainer
list vs what I have installed? That sort of quick tool would allow
everyone to quickly check to see if what they have/need is on the
poverty list.....
thus encouraging folks to 'adopt' some of these old codes; ymmv.
2. I have many old, james_created, eapi-5 ebuilds locally on my systems.
I'd like a way to keep them organized separately, but yet have one
master list to work off of. Ideas/suggestions how to organized this?
I currently place ebuilds of others in
/var/lib/layman. My ebuilds and codes are mostly in /usr/local/portage.
I probably should have another dir, just for embedded gentoo (centric)
devices..... but one master gui to easily view what code are where.
Perhaps distinguish the builds, the ebuilds that do not yet work, and
the raw C codes?
3.
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#Proxied_Maintainer_gets
Perhaps one of the devs could throw up a quick gentoo doc, on suggested
tools? Perhaps the proxy-maintainers have organized the tools and howtos
and other info/intel, so an old, challenged hack like myself can quickly
become 'literate' with the latest and best methods to maintain some of
these old codes? I'm not necessarily up on the latest, most-efficient
ways to organize lots of codes, ebuilds and otherwise.
4. I have not had the time to fully digest git*, so some simple
examples, centric to helping to maintain these old codes, would be a
very positive idea, to encourage folks to commit to helping, beyond
'repoman vs CI'. Perhaps Proxy-maintainers has some examples, I've missed?
5. An additional column to newer codes that supersede these old codes
would optimize the decisions that helpers make of where to invest their
time wisely. Perhaps an additional column point to newer/better codes?
6. An additional column that points out the entries that are
based/depend on python2_7? Or just a parsed listing of such ebuilds.
Any other ideas/suggestions are most welcome.
James
