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 http://nim.fedorapeople.org/argyllcms/ 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.