[argyllcms] Re: Argyll CMS in Fedora (and Mandriva)

  • From: Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 13 Dec 2007 23:25:13 +0100

Le vendredi 14 décembre 2007 à 00:16 +1100, Graeme Gill a écrit :
> Patrice Vetsel wrote:
> > I'm trying to make an Ubuntu(Debian) package of argyllcms too, since
> > one week, and it's difficult because of jam use, and because i'm a
> > novice in packaging.

Patrice: it took three people from two different distributions to hammer
what we have in Fedora now, any one of us would have given up without
the others. Honestly if you're new to packaging you're going to suffer
more than a week, Argyll is *hard*. Or just alien one of our rpms.

> My plan (I think) is to switch to boost Jam, to address some of
> problems with current Jam, although I haven't had the time to
> address this yet.

bjam is better than jam, but to be honest no jam is better than any jam
for us poor packagers.

> > Graeme Gill, do you plan to take care of patches made in Fedora and so
> > , do you are planing to release a new beta version soon ? (kind of
> > christmas release ;) )
> I've tracked the bug fixes, but I haven't addressed all the warnings
> thrown up yet. I'm also half way through some other changes, although
> it's at a relatively stable point right this minute. I was also
> hoping that Hal V. Engel might get back to me with some hints about
> the problems he's had running his Huey under MSWindows XP.

What we're seing under Linux is the Huey declares itself as an HID
device so it gets grabbed by the generic HID driver.

> > Is it possible to have an .ksh script (like makeall.ksh) that do a clean
> > installation of argyllcms in /usr/ (taking care of a path givin in
> > parameter - default in /usr/local), this will simplify installation from
> > sources, and also packaging for distributions.
> I'm not sure exactly what you're after. The top level script is rather
> a hack to compensate for Jam not handling both top down and bottom up
> builds. I'm hoping boost Jam will solve this, although it won't solve
> the circular dependency issues.

The exact problem we have is if we run jam through a script, the shell
intercepts all build errors (and we don't want to ignore them), and if
we loop through jam files in rpm, any incomplete build due to missing
circular deps will stop the build.

> The serial and USB access permissions on the instruments is also a
> problem. I have no clear picture of how different distributions
> are organizing such things with regard to hotplug or udev, all I
> know from feedback is that all the systems seem to do things differently,
> and it all seems poorly documented.

I've reworked the perm files in my latest dump
after consulting David Zeuthen of PolicyKit fame (after some nudging by
Frédéric). They should be pretty authoritative for any modern distro, as
PolicyKit is supposed to be the Linux desktop Future®

> This makes it difficult to write portable code!
> > Why do you are providing libtiff and libusb in sources ? 
> For portability. It makes Argyll self contained, and not dependent
> on the availability or versions of other libraries.

Unfortunately this does not help distributors as our first task is to
rip them out.

>  This particularly
> applies to the binary distributions. I've also had to modify libusb
> to get it to work properly with certain instruments (libusb/darwin.c and
> libusb/linux.c).

Can your get your changes in libusb upstream? Because we're definitely
not going to wander in libusb fork-land @fedora.

> In principle for libtiff, yes, although I'm not familiar with how 
> distributions are
> typical organized to be able to go about it.

Ideally we do a ./configure make make install and let the
upstream-provided build scripts pick up and link against our system
libs. On modern systems pkg-config is pervasive and used by configure
and friends to pick up the right build/link flags

>  I'm not so sure about libusb though
> because of my modifications.

Well since Fedora's and Mandriva's packages are now linked against
system libusb we're going to find out sooner or later.


Nicolas Mailhot

Other related posts: