[gentoo-user] Re: Bouncing messages from [e-mail]

[james]

On 1/25/20 12:32 PM, gentoo-user+owner@l.g.o 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