On 02/25/10 at 10:49am, Aaron Griffin wrote:

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) wrote:

...

I've always thought the method of modifying your local mirrorlist, running mkarchroot, then reverting the changes to be more tedious than necessary for creation of i686 chroots on x86_64. My recent work with setting up a dedicated build server gave me plenty of time and an excuse to actually do something about it. As such, I've put together a little patch that allows specification of creation of an i686 chroot at runtime. When set, this flag will automatically modify your local mirrorlist, create the requested i686 chroot, then revert the changes to the mirrorlist file. I don't know if others would find this useful or not, but I figured it wouldn't hurt to post it.

Actually, I *thought* I added a flag to point to an alternate pacman config when building the chroot, to simplify this. So it'd be as simple as:

sed s/x86_64/i686/ < /etc/pacman.d/mirrorlist > /etc/pacman.d/mirrorlist-i686 sed s/mirrorlist/mirrorlist-i686/ < /etc/pacman.conf > /etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...

-- You know... somehow I never thought about doing it that way...

On 03/07/2010 02:33 PM, Paul Mattal wrote:

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

...

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) wrote:

...

I've always thought the method of modifying your local mirrorlist, running mkarchroot, then reverting the changes to be more tedious than necessary for creation of i686 chroots on x86_64. My recent work with setting up a dedicated build server gave me plenty of time and an excuse to actually do something about it. As such, I've put together a little patch that allows specification of creation of an i686 chroot at runtime. When set, this flag will automatically modify your local mirrorlist, create the requested i686 chroot, then revert the changes to the mirrorlist file. I don't know if others would find this useful or not, but I figured it wouldn't hurt to post it.

Actually, I *thought* I added a flag to point to an alternate pacman config when building the chroot, to simplify this. So it'd be as simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist> /etc/pacman.d/mirrorlist-i686 sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf> /etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...

Having some uniform turnkey script to build an i686 chroot on an x86_64 box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my x86_64 in makepkg.conf with i686, but not replaced the x86-64 which occur in CFLAGS and CXXFLAGS. If others have done similar things, it might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in chroots describes in detail what must be done for i686 chroots in x86_64 in the wiki page, just in case there are important details I or others have missed.

So here's one for the chroot gurus. It appears that even with all my settings fixed, tomcat doesn't work when built in my i686 chroot on x86_64: http://bugs.archlinux.org/task/18604 Building on an actual i686 box, even in a chroot, works. Can anyone guess why this might be? Are there some guidelines someone can give for evaluating whether or not it's safe to build a package under an i686 chroot on an x86_64 box? It seems there's an increased risk we're putting out broken packages when we build i686 packages in a chroot on an x86_64 box. - P

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

On 03/08/10 at 05:20pm, Paul Mattal wrote:

...

On 03/07/2010 02:33 PM, Paul Mattal wrote:

...

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

...

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) wrote:

...

I've always thought the method of modifying your local mirrorlist, running mkarchroot, then reverting the changes to be more tedious than necessary for creation of i686 chroots on x86_64. My recent work with setting up a dedicated build server gave me plenty of time and an excuse to actually do something about it. As such, I've put together a little patch that allows specification of creation of an i686 chroot at runtime. When set, this flag will automatically modify your local mirrorlist, create the requested i686 chroot, then revert the changes to the mirrorlist file. I don't know if others would find this useful or not, but I figured it wouldn't hurt to post it.

Actually, I *thought* I added a flag to point to an alternate pacman config when building the chroot, to simplify this. So it'd be as simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist> /etc/pacman.d/mirrorlist-i686 sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf> /etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...

Having some uniform turnkey script to build an i686 chroot on an x86_64 box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my x86_64 in makepkg.conf with i686, but not replaced the x86-64 which occur in CFLAGS and CXXFLAGS. If others have done similar things, it might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in chroots describes in detail what must be done for i686 chroots in x86_64 in the wiki page, just in case there are important details I or others have missed.

So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines someone can give for evaluating whether or not it's safe to build a package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages when we build i686 packages in a chroot on an x86_64 box.

- P I've seen a few (rare) cases where a package built for i686 on an x86_64 machine _must_ be run with linux32, just using a 32bit chroot doesn't cut it. This could be one of those cases. On a side note, perhaps I should add a flag on pkgbuild.com to enable this just for those off-the-wall cases...

I'd say to always use linux32... You can get some very strange configure errors without it. I have "makechrootpkg64" as an alias to use "linux64 makechrootpkg" on my system. Allan

On 03/08/10 at 11:32pm, Paul Mattal wrote:

On 03/08/2010 07:16 PM, Allan McRae wrote:

...

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

...

On 03/08/10 at 05:20pm, Paul Mattal wrote:

...

On 03/07/2010 02:33 PM, Paul Mattal wrote:

...

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

...

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) wrote: >I've always thought the method of modifying your local mirrorlist, >running mkarchroot, then reverting the changes to be more tedious >than >necessary for creation of i686 chroots on x86_64. My recent work with >setting up a dedicated build server gave me plenty of time and an >excuse to actually do something about it. As such, I've put >together a >little patch that allows specification of creation of an i686 chroot >at runtime. When set, this flag will automatically modify your local >mirrorlist, create the requested i686 chroot, then revert the changes >to the mirrorlist file. I don't know if others would find this useful >or not, but I figured it wouldn't hurt to post it.

Actually, I *thought* I added a flag to point to an alternate pacman config when building the chroot, to simplify this. So it'd be as simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist> /etc/pacman.d/mirrorlist-i686 sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf> /etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...

Having some uniform turnkey script to build an i686 chroot on an x86_64 box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my x86_64 in makepkg.conf with i686, but not replaced the x86-64 which occur in CFLAGS and CXXFLAGS. If others have done similar things, it might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in chroots describes in detail what must be done for i686 chroots in x86_64 in the wiki page, just in case there are important details I or others have missed.

So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines someone can give for evaluating whether or not it's safe to build a package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages when we build i686 packages in a chroot on an x86_64 box.

- P I've seen a few (rare) cases where a package built for i686 on an x86_64 machine _must_ be run with linux32, just using a 32bit chroot doesn't cut it. This could be one of those cases. On a side note, perhaps I should add a flag on pkgbuild.com to enable this just for those off-the-wall cases...

I'd say to always use linux32... You can get some very strange configure errors without it. I have "makechrootpkg64" as an alias to use "linux64 makechrootpkg" on my system.

I've added linux32 to my build scripts on my x86_64 box, since this seems like a good idea in general; is there any reason *not* to run makechrootpkg for an i686 chroot on an x86_64 box with linux32 all the time? I could try to tool up a patch to makechrootpkg to automatically detect/do that.

However, adding it doesn't solve the tomcat building problem; same result. This must be some other issue.

- P OK... take two at an explanation... the go package won't build in an i686 chroot because the build scripts natively use uname to determine arch... possibly something similar in tomcat? --

On 03/09/2010 12:19 AM, Allan McRae wrote:

On 09/03/10 14:40, Daniel J Griffiths (Ghost1227) wrote:

...

On 03/08/10 at 11:32pm, Paul Mattal wrote:

...

On 03/08/2010 07:16 PM, Allan McRae wrote:

...

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

...

On 03/08/10 at 05:20pm, Paul Mattal wrote:

...

On 03/07/2010 02:33 PM, Paul Mattal wrote: > On 02/25/2010 11:49 AM, Aaron Griffin wrote: >> On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) >> wrote: >>> I've always thought the method of modifying your local mirrorlist, >>> running mkarchroot, then reverting the changes to be more tedious >>> than >>> necessary for creation of i686 chroots on x86_64. My recent >>> work with >>> setting up a dedicated build server gave me plenty of time and an >>> excuse to actually do something about it. As such, I've put >>> together a >>> little patch that allows specification of creation of an i686 >>> chroot >>> at runtime. When set, this flag will automatically modify your >>> local >>> mirrorlist, create the requested i686 chroot, then revert the >>> changes >>> to the mirrorlist file. I don't know if others would find this >>> useful >>> or not, but I figured it wouldn't hurt to post it. >> >> Actually, I *thought* I added a flag to point to an alternate >> pacman >> config when building the chroot, to simplify this. So it'd be as >> simple as: >> >> sed s/x86_64/i686/< /etc/pacman.d/mirrorlist> >> /etc/pacman.d/mirrorlist-i686 >> sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf> >> /etc/pacman-i686.conf >> >> mkarchroot -C /etc/pacman-i686.conf ...yada yada... > > Having some uniform turnkey script to build an i686 chroot on an > x86_64 > box as part of devtools would be useful. > > I just noticed today that in setting up my chroots, I had > replaced my > x86_64 in makepkg.conf with i686, but not replaced the x86-64 which > occur in CFLAGS and CXXFLAGS. If others have done similar things, it > might result in buggy or suboptimal packages. > > It would at least be nice of someone who knows a lot about > building in > chroots describes in detail what must be done for i686 chroots in > x86_64 > in the wiki page, just in case there are important details I or > others > have missed.

So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines someone can give for evaluating whether or not it's safe to build a package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages when we build i686 packages in a chroot on an x86_64 box.

- P I've seen a few (rare) cases where a package built for i686 on an x86_64 machine _must_ be run with linux32, just using a 32bit chroot doesn't cut it. This could be one of those cases. On a side note, perhaps I should add a flag on pkgbuild.com to enable this just for those off-the-wall cases...

I'd say to always use linux32... You can get some very strange configure errors without it. I have "makechrootpkg64" as an alias to use "linux64 makechrootpkg" on my system.

I've added linux32 to my build scripts on my x86_64 box, since this seems like a good idea in general; is there any reason *not* to run makechrootpkg for an i686 chroot on an x86_64 box with linux32 all the time? I could try to tool up a patch to makechrootpkg to automatically detect/do that.

However, adding it doesn't solve the tomcat building problem; same result. This must be some other issue.

- P OK... take two at an explanation... the go package won't build in an i686 chroot because the build scripts natively use uname to determine arch... possibly something similar in tomcat?

linux32 will change uname appropriately.

allan@arch ~

...

linux32 uname -m i686

allan@arch ~

...

linux64 uname -m x86_64

So this is a weird one, but I think I just made some headway. Apparently, this seems to be related to the ACTUAL CPU of the box I build on. When building on an i686 Arch box running on an AMD 64 CPU, the build generates the broken binaries! When I build on an Intel CPU, it works fine. So it would appear this is at least in part Tomcat's build process's fault for not building the right thing based on the uname -m but rather looking directly at the processor. Yuck. Perhaps I will at least add a note to the PKGBUILD suggesting this issue, so that the next poor person who decides to update tomcat doesn't trip over this same thing. Thanks, all, for working this through with me. - P

On 09/03/10 14:32, Paul Mattal wrote:

On 03/08/2010 07:16 PM, Allan McRae wrote:

...

On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:

...

On 03/08/10 at 05:20pm, Paul Mattal wrote:

...

On 03/07/2010 02:33 PM, Paul Mattal wrote:

...

On 02/25/2010 11:49 AM, Aaron Griffin wrote:

...

On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227) wrote: > I've always thought the method of modifying your local mirrorlist, > running mkarchroot, then reverting the changes to be more tedious > than > necessary for creation of i686 chroots on x86_64. My recent work > with > setting up a dedicated build server gave me plenty of time and an > excuse to actually do something about it. As such, I've put > together a > little patch that allows specification of creation of an i686 chroot > at runtime. When set, this flag will automatically modify your local > mirrorlist, create the requested i686 chroot, then revert the > changes > to the mirrorlist file. I don't know if others would find this > useful > or not, but I figured it wouldn't hurt to post it.

Actually, I *thought* I added a flag to point to an alternate pacman config when building the chroot, to simplify this. So it'd be as simple as:

sed s/x86_64/i686/< /etc/pacman.d/mirrorlist> /etc/pacman.d/mirrorlist-i686 sed s/mirrorlist/mirrorlist-i686/< /etc/pacman.conf> /etc/pacman-i686.conf

mkarchroot -C /etc/pacman-i686.conf ...yada yada...

Having some uniform turnkey script to build an i686 chroot on an x86_64 box as part of devtools would be useful.

I just noticed today that in setting up my chroots, I had replaced my x86_64 in makepkg.conf with i686, but not replaced the x86-64 which occur in CFLAGS and CXXFLAGS. If others have done similar things, it might result in buggy or suboptimal packages.

It would at least be nice of someone who knows a lot about building in chroots describes in detail what must be done for i686 chroots in x86_64 in the wiki page, just in case there are important details I or others have missed.

So here's one for the chroot gurus.

It appears that even with all my settings fixed, tomcat doesn't work when built in my i686 chroot on x86_64:

http://bugs.archlinux.org/task/18604

Building on an actual i686 box, even in a chroot, works.

Can anyone guess why this might be? Are there some guidelines someone can give for evaluating whether or not it's safe to build a package under an i686 chroot on an x86_64 box?

It seems there's an increased risk we're putting out broken packages when we build i686 packages in a chroot on an x86_64 box.

- P I've seen a few (rare) cases where a package built for i686 on an x86_64 machine _must_ be run with linux32, just using a 32bit chroot doesn't cut it. This could be one of those cases. On a side note, perhaps I should add a flag on pkgbuild.com to enable this just for those off-the-wall cases...

I'd say to always use linux32... You can get some very strange configure errors without it. I have "makechrootpkg64" as an alias to use "linux64 makechrootpkg" on my system.

I've added linux32 to my build scripts on my x86_64 box, since this seems like a good idea in general; is there any reason *not* to run makechrootpkg for an i686 chroot on an x86_64 box with linux32 all the time? I could try to tool up a patch to makechrootpkg to automatically detect/do that.

I see no reason not to. But I do not know the best way to automatically detect the arch. Allan