On Sat, Jun 08, 2013 at 02:18:48PM -0500, Nathan Whitehorn wrote: > On 06/08/13 14:17, Glen Barber wrote: > > On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: > >> On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: > >> > >>> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: > >>>>> Has anyone else tried the i386 memstick and having the same problem? > >>>>> > >>>> Hmm. Thanks for the report. I'll take a look at the logs for i386, but > >>>> they are generated the same way as the amd64, so in theory should not > >>>> have any noticable difference. > >>>> > >>> For amd64 and i386, native binaries are built, and installed into > >>> scratch directories; for powerpc and powerpc64, I just use the amd64 > >>> binaries, because I cannot directly use the chroot binaries for > >>> non-native architecture. > >>> > >>> The scripts chroot into the scratch directories, and run the "real" > >>> release builds. > >> Have you tried using Crochet for this sort of thing? > >> > >> Since it was designed from the ground up for cross-building > >> bootable images, it should avoid these issues. > >> > > I have not, primarily because I was not aware of crochet when > > I originally started this. Although, by using the release stuff from > > the base system, we do get a weekly run-test of the 'make release' bits > > in head/ and stable/9/, so in theory, there would be no surprises when > > it is -RELEASE time. > > > >> The only fundamental limit right now is that Crochet uses > >> the host system to build the UFS filesystems, so it can't > >> build big-endian MIPS images on i386, for example. > >> > >> > > Yes, I have this same issue with sparc64. > > > > Why not use makefs? It can build cross-endian UFS images. The scripts do (as far as I recall for sparc64) use makefs, but a port is needed to create the sparc-capable ISO image. Glen
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC