On 08/16/18 02:07, Andrew Udvare wrote:
> gcruft seems to have died off (https://www.google.com/search?q=gcruft
> only returns ebuild results). 

It might (not really sure) be active but it appears to still be around
as ebuilds::

eix -R gcruft
* app-portage/gcruft
     Available versions:  ~0.1-r1^m[1] ~0.1-r1^m[2] ~0.1.1^m[1] ~0.1.1^m[2]
     Homepage:            http://www.genoetigt.de/site/projects/gcruft
     Description:         helps finding orphaned files on a gentoo system





> I was using it quite a lot and wrote many
> exception files. It's gone now with no way for my or anyone else's
> ebuild to get the original source. I did preserve it though, here:
> https://gitlab.com/Tatsh/gcruft

Thanks for caring!


> I wrote a replacement in C named gcrud. It only needs GLib2 installed to
> work. It's much faster than gcruft ever was. The code is here:
> 
> https://gitlab.com/Tatsh/gcrud
> https://github.com/Tatsh/gcrud


It's going to take me a while to get aroud to testing, but I really
really like admin codes in "C" so it is automatically on my short list....

> 
> I am placing preference in GitLab for issues and merge requests, but I
> will accept PRs from GitHub.

I really like the like gitlab for a variety of reason. I sure wish some
would put together a gitlab-meta ebuild for gentoo. I'd like to house
codes locally, and export relevant open source codes to a online
location, or distributed among a collective of gitlab-gentoo sites.


Complementary to github and our github-centric-dev community.


> 
> The whitelist https://gitlab.com/Tatsh/gcrud/blob/master/whitelist.c is
> currently hard-coded and limited but the results are satisfactory for
> now in my use cases.
> 
> Type use case:
> 
> sudo ./gcrud | sort -u > out.log
> 
> Examine out.log for things you can delete. There are absolutely zero
> calls to delete files from the machine in my code and never will be any
> kind of automation support.

That your choice and I respect that call. However (and it's a big
however), my gentoo-centric HPC cluster do need automated system
cleanup. So, initial, it's be an army of scripts, similar to your code,
that is mandatory in a "loosely coupled" heterogeneous clusters, not to
mention first-line security related cleanup.

> If anyone tries it out I certainly would like to see your output and get
> some bug reports or suggestions. The main feature planned is reading
> from a configuration file for exact file paths and regexs.

Yes, but, it'll be  while for me. Offer and automated clean up option,
and I have dozens of systems to test.....
> 
> --
> Andrew

Thank you Andrew for your work. It can also be very useful to my DAG
efforts for compiling, verifying, and clean up of cluster codes.


GLEP 64 was on the path to systematically solve what you you are doing
after the fact::

https://wiki.gentoo.org/wiki/GLEP:64

More refs for your convenience

http://asic-linux.com.mx/~izto/checkinstall/

http://gittup.org/tup/
("It will automatically clean-up old files.")


hth,
James



Reply via email to