re: packaging ArgyllCMS for Fedora, et. al., I certainly hope that any difficulties to its addition can be overcome, it'd be a great addition! Also, somewhat (OT) but still relevant to CMS packaging and complementary utilities, I think it'd also be great to see LPROF and PHOTOPRINT packaged since then there'd be several new CMS-aware tools available for Fedora and so would synergize well with the capabilities of ArgyllCMS, and other already existing packages like Krita, Scribus, DigiKam, CinePaint, LCMS, et. al. Perhaps even some kind of "CMS AWARE" RPM GROUP tag or something could be added for packages that are built with CMS support so it'd be easier for users to locate and install them. I wonder if there's any tool to implement ICC aware transforms on spooled print jobs for CUPS / Foomatic / Gutenprint. It seems like one can embed a ICC tag into files that are to be printed but AFAIK there's nothing that actually does (as a print filter / option) anything with that such as converting from source ICC to printer colorspace. q.v., both GPL, AFAIK: http://www.blackfiveservices.co.uk/photoprint.shtml http://lprof.sourceforge.net/ Oh and back on the topic of ArgyllCMS and Fedora packaging (compiler options), LINUX use, performance in general, et. al. I notice that some of ArgyllCMS's calculations can be a bit CPU intensive. I wonder if the following compilation options could be of help in performance: http://gcc.gnu.org/gcc-4.2/changes.html > New Targets and Target Specific Improvements > IA-32/x86-64 > > * -mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction. > New Languages and Language specific improvements > OpenMP is now supported for the C, C++ and Fortran compilers. Actually I'm not quite sure about why that's listed; AFAIK OpenMP has (seemingly) been working pretty well for a while in GCC, at least I've used it before in some programs. It might be a relatively easy way to parallelize some of the compute intensive tasks across multiple CPU cores without a lot of code development overhead, and without breaking the compilation on compilers / CPUs that don't support OpenMP or multi-cores.