[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Continued Emapthy Trial

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)
> #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 :)


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: pgpaM7rxtSKKC.pgp
Description: PGP signature

Reply to: