From: Theodore Ts'o <tytso@mit.edu>
To: George Spelvin <linux@horizon.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Exciting :-( adventures in metadata checksumming
Date: Mon, 6 Aug 2012 19:25:12 -0400 [thread overview]
Message-ID: <20120806232512.GE30677@thunk.org> (raw)
In-Reply-To: <20120806225937.17241.qmail@science.horizon.com>
On Mon, Aug 06, 2012 at 06:59:37PM -0400, George Spelvin wrote:
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> debuild: fatal error at line 1350:
> dpkg-buildpackage -rfakeroot -d -us -uc -b -ai386 failed
I don't think -ai386 will work for e2fsprogs since we need external
libraries; specifically, libblkid-dev and libuuid-dev and the dev
packages aren't multiarch compatible. (In fact, I'm not sure -ai386
to build 32-bit packages in an x86 environment will work in general.
It's certainly not the standard way 32-bit packages are built.)
The failures you're seeing is because "pkg-config --libs blkid" is
returning a null string when run in the dpkg-buildpackage -ai386
environment --- which is not surprising, since we don't have a -32/-64
bit link libraries in libblkid-dev.
So if you want to build a 32-bit set of packages of e2fsprogs, you'll
need to make a 32-bit build environment as a chroot, using debootstrap
and build e2fsprogs in the 32-bit chroot.
That's actually how I build my packages for Debian, BTW --- I have a
32-bit chroot, and I build the binary packages for i386 and upload
them from there. I let the autobuilders build the 64-bit binary
packages from the source upload. That way, the most commonly used
binary packages are built in a standard autobuilder environment, and
are not subject to the vagracies of my build environment. It also
means that I don't have to worry about the build scripts bitrot for
the 32-bit packages. (I also build 64-bit debs for my own use --- but
I don't upload them.)
Regards,
- Ted
next prev parent reply other threads:[~2012-08-06 23:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-03 19:55 Exciting :-( adventures in metadata checksumming George Spelvin
2012-08-03 23:49 ` Theodore Ts'o
2012-08-04 1:42 ` George Spelvin
2012-08-04 22:12 ` Theodore Ts'o
2012-08-04 22:41 ` George Spelvin
2012-08-06 16:47 ` Theodore Ts'o
2012-08-06 18:14 ` George Spelvin
2012-08-06 22:12 ` Theodore Ts'o
2012-08-06 22:59 ` George Spelvin
2012-08-06 23:25 ` Theodore Ts'o [this message]
2012-08-08 13:39 ` metadata_csum Oops George Spelvin
2012-08-08 22:34 ` Exciting :-( adventures in metadata checksumming George Spelvin
2012-08-08 23:42 ` George Spelvin
2012-08-09 5:00 ` George Spelvin
2012-08-09 23:48 ` Arrgh! Even more excitement with " George Spelvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120806232512.GE30677@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux@horizon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.