Re: [bug-gsrc] paxutils tar out of date

[Brandon Invergo]

>     Maybe it would be a good idea to bring this issue to g-p-d?
>
> No, that would be a terrible idea, unless your goal is to generate 100
> useless pieces of off-topic email :).

...branched into 3 different threads....

> More generally, there are many GNU packages in various stages of
> staleness.  I've talked to all the maintainers.  Sometimes things
> eventually get updated, other times, not.  Sometimes eventually the
> maintainer resigns or disappears (so we look for a new one), or the
> package get decomissioned, or some other outcome is reached.  Sometimes
> not.  That's life.  It's not realistic to expect every package to be up
> to date, although that is surely the theoretical goal that rms/karl/all
> are always working toward.

I think ideally, a minimal goal should be to keep everything at least
building properly, even if they're no longer being updated with new
features. But I can imagine that maintainers lose interest in even doing
that minimal effort sometimes, or life situations change, etc. So yeah,
it's probably inevitable sometimes that packages end up in a state of
developmental torpor.

Now that I've gone through basically all of the GNU packages for GSRC, I
would say the most widespread problem we face is the dependence of some
older packages on GNOME/GTK 1. As far as I can tell, unlike GTK 2, it
does not seem feasible to build GTK 1 anymore (not based on my trials at
least). This means that there are several current packages for which the
build fails due to their old GTK dependency.

That list is approximately:
- halifax viewer/sender
- ggradebook
- gnusound
- gpaint (actually depends on GTK 2, but uses deprecated lib calls)
- ignuit
- spacechart
- xhippo (Adam Sampson has made a follow-up project called Potamus,
which is non-GNU, so his interest in xhippo is questionable)
- xlogmaster

Do we have any resident GTK gurus? :) I have some experience with GTK 2
& 3, but I don't know what the API used to look like.

My main focus with GSRC will begin to be about fixing broken builds. So
hopefully over time I'll have built up a solid set of patches for these
projects that can perhaps get merged in by their maintainers; if the
maintainer doesn't respond, I suppose in such cases I could step in as a
temporary maintainer in the purest sense of the word only (ie
maintenance only, not really active development). 

Well, let's wait until my fabled patches start arriving before doing
anything drastic like taking over projects...

BTW, GSRC's TODO file lists all the broken packages, with terse (not very
useful) notes. I have *not* filed bug reports for all of them yet,
though I know that's the correct thing to do.


> As long as I'm writing about such things: if anyone here has time and
> interest in working on grep or sed, they are by far the highest profile
> packages that need maintainers now.

Interested for sure, having read through the grep code before, but no
time unfortunately to commit myself to something so high profile. Not at
least until this damn PhD is finished...

-brandon