> "Jon Ciesla" <limb@xxxxxxxxxxxx> writes: >>> (Yes, I know libjpeg upstream is kinda moribund, but if you want new >>> features in it you should be trying to revive upstream development, >>> not strongarm the Fedora package maintainer to take over development.) > >> I agree strongly with that principle. Two questions: > >> A. What has been done thusfar WTR reviving upstream development? > > Well, at one point I had more or less formally blessed Guido Vollbeding > as the new lead maintainer, but if he's actually put out a release I > haven't heard about it :-(. You could try bugging the people associated > with the sourceforge libjpeg project. CCing them. libjpeg SourceForge team, what is the current status of libjpeg development? >> B. In the meantime, how should I support jpegtran? Bundle a custom >> binary >> in the subpackage and patch the module, or let it sit with known partial >> functionality? > > The right fix would be to pester upstream to not depend on nonstandard > functionality, but with no active upstream on that side either, I'm not > sure what you do about it :-(. How critical is that particular > functionality to gallery2, anyway? If you could just dike it out that > would seem to be an appropriate short-term fix. Not critical at all, AFAICT. I'll have a look-see. >> On a tangential note IIRC this patch is in Debian's libjpeg, not that >> that >> should be any sort of guideline for us, I'm just putting it out there. > > Yeah, Debian seems to have no qualms about carrying big patches without > any upstream connection ... No comment. :) > regards, tom lane > -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
