farbot - Project Hosting on Google Code

Earlier this year Jul 11, 2009 farbot-1.0.tar.gz.asc (farbot 1.0 GnuPG signature) file uploaded by nick.barkas - Labels: Featured Labels: Featured Jul 11, 2009 farbot-1.0.tar.gz (Farbot 1.0) file uploaded by nick.barkas - Labels: Featured Labels: Featured Jul 11, 2009 r329 (Created tags/farbot-1.0 from trunk for release 1.0.) committed by nick.barkas - Created tags/farbot-1.0 from trunk for release 1.0. Created tags/farbot-1.0 from trunk for release 1.0. Jul 11, 2009 r328 (Missed part of that comment ) committed by nick.barkas - Missed part of that comment Missed part of that comment Jul 11, 2009 r327 (- Add some information about running this at the top - pushd...) committed by nick.barkas - - Add some information about running this at the top - pushd and popd aren't necessarily built-in to non-bash bourne shells (e.g. ash on FreeBSD) - Allow specifying path to docbook-xsl stylesheets on command line, overriding the default directory specified in the docs make file. - Add some information about running this at the top - pushd and popd aren't necessarily built-in to non-bash bourne shells (e.g. ash on FreeBSD) - Allow specifying path to docbook-xsl stylesheets on command line, overriding the default directory specified in the docs make file. Jul 11, 2009 r326 (Don't install the css file with execute permissions. No need...) committed by nick.barkas - Don't install the css file with execute permissions. No need for this Makefile to have them either. Don't require PREFIX to be set for finding the stylesheet, just explicitly use DOCBOOK_XSL. /usr/local/share/xsl/docbook is where it is when installed using FreeBSD ports, and it is easy enough to override DOCBOOK_XSL from the environment on other systems Don't install the css file with execute permissions. No need for this Makefile to have them either. Don't require PREFIX to be set for finding the stylesheet, just explicitly use DOCBOOK_XSL. /usr/local/share/xsl/docbook is where it is when installed using FreeBSD ports, and it is easy enough to override DOCBOOK_XSL from the environment on other systems Jul 11, 2009 r325 (I can commit changes to the port directly to FreeBSD's CVS, ...) committed by nick.barkas - I can commit changes to the port directly to FreeBSD's CVS, so there isn't much point in trying to keep another copy here in sync. I can commit changes to the port directly to FreeBSD's CVS, so there isn't much point in trying to keep another copy here in sync. Jul 11, 2009 r324 (Missing s ) committed by nick.barkas - Missing s Missing s Jul 11, 2009 r323 (Add script to aid in release creation, based on Jonathan's i...) committed by nick.barkas - Add script to aid in release creation, based on Jonathan's in jpkg-library Add script to aid in release creation, based on Jonathan's in jpkg-library Apr 22, 2009 farbot-1.0-beta2.tar.gz.asc (GnuPG signature) file uploaded by nick.barkas Jan 16, 2009 r322 (In case EC2 ever supports FreeBSD... ) committed by nick.barkas - In case EC2 ever supports FreeBSD... In case EC2 ever supports FreeBSD... Older Dec 18, 2008 issue 1 (Add support for building i386 releases/packages on amd64) commented on by nick.barkas - Jayme reports that "the tftp boot loader is the i386 version on both i386 and amd64" Jayme reports that "the tftp boot loader is the i386 version on both i386 and amd64" Dec 09, 2008 r321 (It would be nice to not have to create different disk sets j...) committed by nick.barkas - It would be nice to not have to create different disk sets just for differing amounts of physical RAM in machines. It would be nice to not have to create different disk sets just for differing amounts of physical RAM in machines. Nov 04, 2008 r320 (Change URLs to point to Google project hosting site instead ...) committed by nick.barkas - Change URLs to point to Google project hosting site instead of dpw.threerings.net. Also give myself some credit in the manual :) Change URLs to point to Google project hosting site instead of dpw.threerings.net. Also give myself some credit in the manual :) Aug 15, 2008 issue 1 (Add support for building i386 releases/packages on amd64) commented on by s...@moduli.net - Also, farbot currently only uses a single tftproot directory, so the boot loader and kernel will be the same for all releases. It would be better probably to use a tftproot directory for each release, or at least each architecture. This will make it trickier to configure the DHCP server since it will have to use different root-path and filename settings for machines with different desired releases, probably requiring an administrator to put MAC addresses directly into the DHCP configuration file. Also, farbot currently only uses a single tftproot directory, so the boot loader and kernel will be the same for all releases. It would be better probably to use a tftproot directory for each release, or at least each architecture. This will make it trickier to configure the DHCP server since it will have to use different root-path and filename settings for machines with different desired releases, probably requiring an administrator to put MAC addresses directly into the DHCP configuration file. Aug 13, 2008 issue 1 (Add support for building i386 releases/packages on amd64) commented on by s...@moduli.net - Er, that's /libexec/ld-elf32.so.1 and /libexec/ld-elf.so.1 Er, that's /libexec/ld-elf32.so.1 and /libexec/ld-elf.so.1 Aug 13, 2008 issue 1 (Add support for building i386 releases/packages on amd64) reported by s...@moduli.net - As it stands now, it is not possible to build i386 releases or packages on amd64 farbot build servers without some tweaking. When using binary releases packages cannot be built unless ARCH i386 is set in the release's PackageBuildOptions, and this should be automatic. Furthermore it is necessary to symlink /libexec/ld-elf.so to /libexec/ld-elf32.so in the package build chroot before farbot chroots there and starts building packages. An option should be added to the farbot.conf file to just specify that the architecture of the release is something other than what the build server runs to make this happen automatically. I've not yet tested cross-building a release from source using a different architecture, but I suspect that TARGET and TARGET_ARCH will need to be set to i386 for building the kernel and world. Cross compiling for other architectures would be cool, but supporting that I'm sure will be harder if possible at all. Plus I don't have any non-i386/amd64 hardware to test with. For now let's try just being able to build i386 on amd64. As it stands now, it is not possible to build i386 releases or packages on amd64 farbot build servers without some tweaking. When using binary releases packages cannot be built unless ARCH i386 is set in the release's PackageBuildOptions, and this should be automatic. Furthermore it is necessary to symlink /libexec/ld-elf.so to /libexec/ld-elf32.so in the package build chroot before farbot chroots there and starts building packages. An option should be added to the farbot.conf file to just specify that the architecture of the release is something other than what the build server runs to make this happen automatically. I've not yet tested cross-building a release from source using a different architecture, but I suspect that TARGET and TARGET_ARCH will need to be set to i386 for building the kernel and world. Cross compiling for other architectures would be cool, but supporting that I'm sure will be harder if possible at all. Plus I don't have any non-i386/amd64 hardware to test with. For now let's try just being able to build i386 on amd64.

issue 1 (Add support for building i386 releases/packages on amd64) reported by s...@moduli.net - As it stands now, it is not possible to build i386 releases or packages on amd64 farbot build servers without some tweaking. When using binary releases packages cannot be built unless ARCH i386 is set in the release's PackageBuildOptions, and this should be automatic. Furthermore it is necessary to symlink /libexec/ld-elf.so to /libexec/ld-elf32.so in the package build chroot before farbot chroots there and starts building packages. An option should be added to the farbot.conf file to just specify that the architecture of the release is something other than what the build server runs to make this happen automatically. I've not yet tested cross-building a release from source using a different architecture, but I suspect that TARGET and TARGET_ARCH will need to be set to i386 for building the kernel and world. Cross compiling for other architectures would be cool, but supporting that I'm sure will be harder if possible at all. Plus I don't have any non-i386/amd64 hardware to test with. For now let's try just being able to build i386 on amd64.

As it stands now, it is not possible to build i386 releases or packages on amd64 farbot build servers without some tweaking. When using binary releases packages cannot be built unless ARCH i386 is set in the release's PackageBuildOptions, and this should be automatic. Furthermore it is necessary to symlink /libexec/ld-elf.so to /libexec/ld-elf32.so in the package build chroot before farbot chroots there and starts building packages. An option should be added to the farbot.conf file to just specify that the architecture of the release is something other than what the build server runs to make this happen automatically. I've not yet tested cross-building a release from source using a different architecture, but I suspect that TARGET and TARGET_ARCH will need to be set to i386 for building the kernel and world. Cross compiling for other architectures would be cool, but supporting that I'm sure will be harder if possible at all. Plus I don't have any non-i386/amd64 hardware to test with. For now let's try just being able to build i386 on amd64.

Earlier this year

Older