On Mon, Jan 11, 2010 at 06:07:08PM -0800, Jared Johnson wrote: > How do I tell pbuilder to pass an option to the configure script? After adding the ~ to the usbutils > in the build-depends it began to compile. However, after a couple compiler errors I realized that > gcc-4.4 and libc6(.1)-dev are needed. I do not feel like backporting all that mess as well, but I > found an option --disable-extras to pass to configure that may allow me to continue on...*cross > fingers*! Could someone let me know how to do this? You don't tell pbuilder, you tell debian/rules to pass that option to the configure script when it is invoked. This is usually done in the "build" or "configure" debian/rules target. In empathy-2.28.2's case, debian/rules uses CDBS, the Common Debian Build System. In this case, it's quite easy to add another configure flag - just open debian/rules, find the DEB_CONFIGURE_EXTRA_FLAGS assignment, and add another extra flag to it :) > Just fyi, the errors so far are due to the usage of the macro le16toh() in > extras/ata_id/ata_id.c which is correctable by the new libc6-dev 2.10 (giving endian.h) or the > following code. > > #if !defined(le32toh) || !defined(le16toh) > #if BYTE_ORDER == LITTLE_ENDIAN > #define le32toh(x) (x) > #define le16toh(x) (x) > #else > #include <byteswap.h> > #define le32toh(x) bswap_32(x) > #define le16toh(x) bswap_16(x) > #endif > #endif If such a patch would fix it without losing functionality, you could try... well, patching the source. You could either do it directly, editing some file and adding this code, in which case the patch would go into the .diff.gz at package building time, or you could try using some patch system - quilt (my personal preference), dpatch, or maybe even CDBS's own simple-patchsys. Unfortunately, I'm not familiar enough with CDBS and I don't know exactly how simple-patchsys is used or how to add quilt to a CDBS rules file - although I think the latter could be as simple as adding another "include" line and then, of course, adding quilt to the build dependencies :) > The next error was in needing linux-libc-dev from backports for /usr/include/linux/bsg.h. > > The current error came from needing libc6-dev and possibly the -i386 version as well for > /usr/include/sys/signalfd.h ... This however needs gcc-4.4-2? Would someone recommend trying the > bpo 4.3 version? Or should I disable the extras (hardware compatibility and some functionality)? > Meanwhile I'll keep trying to get some of the other depends backported:) I guess for the users it might be preferable to have a backport with as close to the "real" package's functionality as possible. However, if it would be too much trouble, maybe --disable-extras could be a reasonable compromise - but make sure you document this in a README.Debian or NEWS.Debian or similar file that is installed on the users' systems, so they are aware of what they're missing :) Then again, please don't give this personal opinion more importance than it is due - it *is* merely the personal opinion of a Debian user, and maybe the backports meisters will pipe in to slap me down with good reason :) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 because I didn't think of a good beginning of it.
Attachment:
pgpL5kUvzwKKm.pgp
Description: PGP signature