Hi Gentoo Team,

As some of you may noticed i started to clean up some old patches in the
gentoo portage tree. I did so already a while ago, and like before I'm
using a small script in order to identify unused patches.

I few days ago i started to hack again on that script and thought about
to make it easier to use the output. The result is following:

http://gentoo.levelnine.at

This is my homepage, were you can see the output of my patchtest and
other scripts (gonna explain below). The scripts gonna run once a day
and sort the findings by package and maintainer.
The scripts itself are hosted on github, you can find them on:

https://github.com/mm1ke/gentoo-scripts

The scripts aren't very polish and probably lacks a lot of
comments and cleanups. However, for now they working as expected and do
help me to find a lot of unused patches.


The scripts:

As mentioned, the homepage actually has 3 scripts running once a day. I
gonna give you a short description of what every script is doing and
what are its limitations.

patchtest:
This is my oldest script, and my main source of lists with unused
patches. I won't go into detail how it exactly works, but it basically
checks every package if there is a "files" dir, creates a list of
pachtes/files included in this dir and greps every ebuild if it can find
any of the patches or files.
As you know this isn't very easy as patches aren't usually written with
their filename in the ebuild, so it has some limitations, which are:
* asterisk:
patching using an asterisk to get the files to patch (like epatch
packagename-vers-patch*.patch) will give false positives.
* special variables (like ${MY_PN})
when scripts use such variables in patchnames it will give false
positives.
* patching like epatch patchname-vers-patch{1,2,3,4}.patch will give
"some" false positives. Just some because I've already added a feature
to identify such naming, but it's still not 100% perfect.
* eclasses which uses files in FILESDIR. Not many do that, but it will
give still a false positive.

I probably forget something, but apart from those limitations it works
quite well. Just have a look at the results.


patchcheck:
This is a spinoff of patchtest. The idea was to identify packages who
have a "files" directory, but no ebuild has the keywords
"FILESDIR,.patch,.diff" and a few eclasses in it.
The result is much smaller then with patchtest, but in this case the
results are more useful as there are just a few false-positives.

wwwtest:
This is a new scirpt, which, as the name might suggest, checks the
homepages of every ebuild. Apart from sorting the output by package and
maintainer it also creates lists by httpcode. That way it's quite easy
to check which homepage aren't available anymore (just look at the 
404.txt file).
The other sortings however doesn't include "good" http codes, which are
for now: 200,302,307,400,503 (this can be changed anytime)
Also links to ftp sites aren't included and are in a separate file
(FTP.txt).
Furthermore, there is another file called VAR.txt. This one includes
packages who use variables in the homepage fild (which i really
don't like). I think i gonna update my script someday to replace the
vars and be able to check them, however special vars like ${MY_PN} gonna
be still a problem...
The 000.txt file contains usually homepages who timed out. Usually i try
10 seconds to get an httpcode before giving up.


Comments, suggestions and even patches are welcomed. :)
I hope someone can use these findings.

Kind regards,
Michael Mair-Keimberger