My checklist when fixing packages

As I wrote I’ll be trying to write more documentation about what I do, rather than doing stuff. This is because I’m simply too tired, and I should rest and relax rather than stress myself.

So after playing some Lego Star Wars I’ve decided to take a look to what I need to document for PAM. There was an easy bug to fix so I decided to tackle that down; tackling that down I decided to look if I was missing anything and I noticed that sys-libs/pam could use a debug USE flag. Unfotunately, not only it does not build with debug USE flag enabled, but it also fails with it disabled because the configure file was written by someone who yet again fail at using AC_ARG_ENABLE.

But this was just one of the two things I noticed today and I wished to fix if I didn’t have to rest, so I decided to write here a small checklist I follow when I have to check or fix packages:

• If the package is using autotools, I make sure they can be rebuilt with a simple autoreconf -i. Usually this fails when macros are present in the m4 directory (or something like that), or if it misses the gettext version specification for autopoint.
• If the package supports out-of-sourcetree builds, I create an “enterprise” directory and build from there (usually it involves a ../configure). A lot of packages fail at this step because they assume that source directory and build directory are one and the same.
• If the package uses assert() I make sure it works with it disabled (-DNDEBUG); this is usually nice to link to the debug USE flag to remove debugging code.
• I check the resulting object files with cowstats (check Introducing cowstats for more information about this), and see if I can improve the situation with some trivial changes.
• I check the resulting object files with missingstatic (another script in ruby-elf).
• If the package uses automake I make sure the _LDFLAGS variables don’t contain libraries to link to (would break --as-needed).
• I check for possible bundled libraries we don’t want to use.
• I check for possible automagic dependencies that we don’t want in the ebuild.
• I run a build with all the useful warnings enabled, and see if there is something that needs to be fixed.

Such a checklist, if done from start to end, may generate a fair amount of patches that have to be sent upstream. It usually requires to check them on their development repositories too so that the patches are not obsoleted already.

As you can guess by now, it’s not exactly the quickest of the tasks, and it depends a lot on the power of the development box I’m working on. Unfortunately using a faster remote box does not always help because, even if Emacs’s tramp is quite neat, it does not make it easy to access the sources for editing. And having the sources locally and mounting them remotely doesn’t resolve either, as the build would then stall on getting the sources.

My plans were to get either the YDL PowerStation or a dual quad-core Opteron system (yes I know it’s overkill, but I don’t want to have to upgrade system every three years). It wouldn’t have been that bad, I just needed to take a couple of jobs during summer and early fall, and I could afford them. Right now, though, the situation looks pretty bad. I’m not sure whether I can get a new job done before fall, and even though medical care in Italy is paid for by the government, there are a few expenses I had to make (like for instance an over-quota for my Internet connection to download the software to view my CAT scans while I was in the hospital — long story, I’ll write about that another day), and the visit next Tuesday is in private practice (so I’ll have to pay for it).

If you care about a package, try to apply these checks on it, and see if upstream can pick up some improvements 🙂 Every little drop is an advantage!