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

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 14 Dec 2007 13:46:20 +1100

Nicolas Mailhot wrote:
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.

It's pretty straight forward from a code point of view, the curliest aspect
being the current circular dependencies. I'm thinking that it might be easier
to fix these with bjam, since it should have a global view of
dependencies, and it should therefore be possible to
break the dependencies without creating a lot of new directories.

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

I just want a cross platform build system that's easy to use. I haven't
found one yet though. I suspect that a cross platform version of Odin
would probably come close. The chief problem with 99% of build systems is
that they are not modular, they all assume a top down description of a
project, which makes it hard to maintain. I'm hoping bjam is moving
in the right direction, and I'd imagine the boost libraries are
pretty widely used.

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

Yep. That type of approach will increase, as vendors try and avoid
MSWindows XP64 and Vista's driver code signing requirements. I switched
to the HID driver interfaces on MSWindows and OS X for Huey to make
it work smoothly, but unfortunately the HID driver on Linux is lacking
critical features (the ability to read and write arbitrary packets
from/to the end points), so libusb has to be used, and a
usb_detach_kernel_driver_np() is done to kick the HID driver out.

Are you saying the usb_detach_kernel_driver_np() doesn't work
correctly on all systems, or is there some other issue ?

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.

Right. Yes, it's not very nice from that point of view at the moment.

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®

Perhaps you can point me to some doco on the sub-system
that uses the .fdi files, as I'm unfamiliar with them ?

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

Right, but this is natural, since we have different goals.

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

I'll try, but I'm not sure if I'll succeed. libusb doesn't seem that actively
maintained, hence the openusb fork.

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

Sorry, Jam is much more lightweight to install that ./configure etc.
on MSWindows, and I'd much rather deal with maintaining a single
system that runs across all platforms, rather than also trying to
maintaining one that's essentially confined to UNIX type systems.

I'm open to other suggestions though, about how to make the Jamfiles
more friendly towards system installed libraries.

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

Likely the Eye-One Pro will be the device that gives problems,
since it is the one that needs to have two threads accessing
different USB end points. The problems occur when the i1pro switch
read thread transaction times out.

Graeme Gill.

Other related posts: