Gentoo Archives: gentoo-user

From: james <garftd@×××××××.net>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: Bouncing messages from
Date: Wed, 05 Feb 2020 00:07:22
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, and 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. 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