On Wed, Apr 23, 2008 at 9:40 PM, Duncan <[EMAIL PROTECTED]> wrote: > "Andy Wang" <[EMAIL PROTECTED]> posted > If you'd kill the HTML next time, some of us would be grateful. Not > everyone here likes webmail, and HTML based messages can be a security > issue, so some of us choose not to enable it or use clients that handle > it. Thanks.
Gmail defaults to multipart html and plain text, and as Volker said in his reply, that shouldn't be a problem with any modern mailer. Given that gentoo is a "geek" distribution, I'm sure there are plenty of legacy e-mail client holdouts thus I will make it a point to try to remember to force plain text formatting (which I've done with this message). Given the volume of mail on this list, I sure as hell am not going to use my regular e-mail account's quota given my 6GB+ gmail quota :) > > I'd use the 32-bit chroot (or build on a 32-bit machine) and use > FEATURES=buildpkg so all the packages ended up as tbz2 binaries. > > For individual cases that should be enough on the build side. On the > binary package consumer, I'd use a 32-bit chroot again (to keep the 32- > bit packages tracked separately from the 64-bit ones) and either emerge > a more or less full system or use package.provided and/or --nodeps when > merging individual packages if I chose not to do the full 32-bit system. > The problem with a 32-bit chroot system is that for things to work properly on a multilib system, 32-bit libraries go in /lib32|/usr/lib32. A standard x86 environment doesn't deal with that. The old instructions at http://www.gentoo.org/proj/en/base/amd64/emul/ basically document doing this with a 32-bit chroot with a custom profile (that's in the portage tree) to deal with the multilib directory structure. However, that howto is obsolete as per Mike Doty's original e-mail on this thread when I started it over half a year ago. Back then the response was maybe in a month or two it would be documented and it still isn't, so I'm asking again just to see if anyone has made any progress on the documentation. > For something more suitable for general distribution, IOW, usable > directly from the main system's portage/other-pm, I'd use the binaries > created in the first step as the "sources", and build an ebuild script > wrapper around them to untar and install them manually (and to an > appropriately different location for libs, or name for executables, than > the 64-bit stuff), while tracking them using emul- (or similar) to keep > them separate from the 64-bit packages of the otherwise same name. The > same skeleton untar and install script could be used for all such > packages, with specific extra configuration, etc. attached as necessary. This doesn't work for libraries that have additional modules that are located in /usr/lib32/[moduledirectory] as I mentioned in my previous comment when you have libraries built in a regular chroot environment with a libdir of /usr/lib, it's going to look for /usr/lib/[moduledirectory]/module.so which will be the 64-bit library and thus incompatible > > That seems fairly straightforward and would the existing portage binary > package capabilities, but is obviously not quite the method they took, as > they have more generalized packages that include binaries (libraries, > etc) from multiple normal packages. The advantage of doing it as above, > however, would be that the generic wrapper ebuild script could be simply > renamed as appropriate to use with 32-bit packages other than those > currently supplied. > > As I said, FWIW... It may or may not be suitable for your purposes. Unless you have a suggestion on how to deal with LIBDIR during configure runs and such, your suggest is unfortunately not suitable for my purposes. What little digging I have been able to do shows that ABI=x86 seems to provide some ability to build 32-bit packages so long as all of the dependencies have been built as 32-bit. Unfortunately, some of the packages I want to build have different header files in /usr/include for 64-bit and 32-bit platforms making it very difficult to build without a chroot environment, but the only chroot environment that I know of that partially works is the one that was documented that is now considered obsolete. -- [email protected] mailing list
