ReBootstrap - Revision history

Drobbins: /* Status */

2012-02-14T07:30:34Z

‎Status

Oleg: cloned portage will be latest branch, checking out tag making a detached mode

2012-01-03T18:16:01Z

cloned portage will be latest branch, checking out tag making a detached mode

Mirell: /* What is Aboriginal Linux? */

2012-01-02T20:32:41Z

‎What is Aboriginal Linux?

Landley: Update plan of attack and prerequisites. New "details" section under plan of attack. Rename "update" to "status".

2012-01-02T01:26:54Z

Update plan of attack and prerequisites. New "details" section under plan of attack. Rename "update" to "status".

Mirell: /* What is Aboriginal Linux? */

2011-12-31T05:38:27Z

‎What is Aboriginal Linux?

Golodhrim at 00:52, 31 December 2011

2011-12-31T00:52:46Z

Golodhrim at 00:52, 31 December 2011

2011-12-31T00:52:09Z

Landley: What's the LFS build?

2011-12-31T00:01:22Z

What's the LFS build?

Landley: Add "how do I use aboriginal linux" section.

2011-12-30T23:16:53Z

Add "how do I use aboriginal linux" section.

Landley: Fluff out new section a bit, switch = with == markup.

2011-12-30T22:58:15Z

Fluff out new section a bit, switch = with == markup.

@@ Line 113: / Line 113: @@
 ### drobbins suggested something like "portage inject packagename USE="flag flag flag" [files...]" to retroactively notify portage of an installed package.  (Aboriginal Linux has a BINARY_PACKAGE_TARBALLS option using "touch timestamp; build package; find output -newer timestamp", and this could be inserted in the LFS build fairly easily.  Or just use a blank file list and not care that portage can't upgrade/uninstall the package, we just need the dependency generation to work.)
 # If package.provided is not working, simply copy <tt>/var/db/pkg</tt> from an existing stage3 for a massive injection of fake package information.
 [[Category:Labs]] [[Category:Projects]]

@@ Line 53: / Line 53: @@
 :wget http://python.org/ftp/python/2.7.2/Python-2.7.2.tar.bz2
 :./configure --prefix=/usr
 :make -j $CPUS
@@ Line 60: / Line 62: @@
 :wget http://git-core.googlecode.com/files/git-1.7.8.2.tar.gz
 :./configure --without-tcltk --without-python --without-iconv
 :make NO_PERL=1
@@ Line 69: / Line 73: @@
 :git clone git://github.com/funtoo/portage-funtoo portage
 :cd portage
 :mkdir -p /usr/share/portage
 :ln -s /usr/lib/portage/cnf /usr/share/portage/config

@@ Line 9: / Line 9: @@
 The resulting system can then boot under QEMU (or on appropriate hardware, if available) to provide a native development environment, eliminating the need for any further cross compiling.  You can wget, configure, make, and install additional source packages inside the emulator.
-Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu".
+Aboriginal Linux's web page is at http://landley.net/aboriginal and a long presentation about it is available at http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu
 == How do I use Aboriginal Linux? ==

@@ Line 3: / Line 3: @@
 = What is Aboriginal Linux? =
-Aboriginal Linux's motto is "we cross compile so you don't have to".  It replaces cross compiling with native compiling under an emulator (generally QEMU).  Funtoo can use it to natively create stage 1/2/3 root filesystems on an arbitrary target, which greatly simplifies adding support for new architectures and regression testing existing architectures.
+Aboriginal Linux's motto is "we cross compile so you don't have to".  It replaces cross compiling with native compiling under an emulator (generally QEMU).  Funtoo can use this to natively create stage 1/2/3 root filesystems on an arbitrary target, which greatly simplifies adding support for new architectures and regression testing existing architectures.
 Aboriginal Linux creates a simple native development environment for each type of target hardware, building the smallest self-contained Linux system capable of rebuilding itself entirely from source code.  This requires seven packages: linux, uClibc, busybox, binutils, gcc, make, and bash.
-The resulting system can then boot under the emulator QEMU (or on appropriate hardware, if available) to provide a native development environment, eliminating the need for any further cross compiling.  You can wget, configure, make, and install additional source packages inside the emulator.
+The resulting system can then boot under QEMU (or on appropriate hardware, if available) to provide a native development environment, eliminating the need for any further cross compiling.  You can wget, configure, make, and install additional source packages inside the emulator.
 Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu".
@@ Line 13: / Line 13: @@
 == How do I use Aboriginal Linux? ==
-Aboriginal Linux provides prebuilt native development environments for x86, x86-64, arm, mips, powerpc, and more, ready to run under the emulator.  Install QEMU 1.0 or later, then go to http://landley.net/aboriginal/downloads/binaries", grab the appropriate system-image tarball, extract it, and run one of the following three shell scripts:
+Aboriginal Linux provides prebuilt native development environments for x86, x86-64, arm, mips, powerpc, and more, ready to run under the emulator.  Install QEMU 1.0 or later, then go to http://landley.net/aboriginal/downloads/binaries", grab the appropriate system-image tarball, extract it, and run one of the following three shell scripts (included in the tarball):
-* ./run-emulator.sh - Boot to a shell prompt, with the simplest configuration: a read-only (squashfs) root filesystem with a tmpfs mounted on /home.
+* '''./run-emulator.sh''' - Boot to a shell prompt, with the simplest configuration: a read-only (squashfs) root filesystem with a tmpfs mounted on /home.
-* ./dev-environment.sh - Boot to a shell prompt with a full development environment.  This wrapper around run-emulator.sh adds a 2 gigabyte ext2 /dev/hdb image mounted on /home (persistent writeable space, in large amounts), and allocates 256 megabytes of physical memory for the emulator (enough to run gcc building complex packages).  If distccd and the appropriate target's cross compiler are available in the host's $PATH, this script also configures the emulated environment to call out to the cross compiler via distcc, transparently moving the heavy lifting of compilation outside of the emulator.
+* '''./dev-environment.sh''' - Boot to a shell prompt with a full development environment.  This wrapper around run-emulator.sh adds a 2 gigabyte ext2 /dev/hdb image mounted on /home (persistent writeable space, in large amounts), and allocates 256 megabytes of physical memory for the emulator (enough to run gcc building complex packages).  If distccd and the appropriate target's cross compiler are available in the host's $PATH, this script also configures the emulated environment to call out to the cross compiler via distcc, transparently moving the heavy lifting of compilation outside of the emulator.
-* ./native-build.sh - Run an automated build.  This requires a "control image", which is a squashfs filesystem the emulated system sees as /dev/hdc mounted on /mnt.  The init script in the emulated root filesystem checks for /mnt/init and if that exists, it runs that instead of providing a shell prompt.  (Actually it asks the user to press a key if they want a shell prompt, with a three second timeout.)  See "http://landley.net/aboriginal/control-images" for details.
+* '''./native-build.sh''' - Run an automated build.  This requires a "control image", which is a squashfs filesystem the emulated system sees as /dev/hdc mounted on /mnt.  The init script in the emulated root filesystem checks for /mnt/init and if that exists, it runs that instead of providing a shell prompt.  (Actually it asks the user to press a key if they want a shell prompt, with a three second timeout.)  See "http://landley.net/aboriginal/control-images" for details.
 (You can build your own system images from source by following the instructions at "http://landley.net/aboriginal", but ReBootstrap does not require this.)
@@ Line 25: / Line 25: @@
 == What is an "LFS build"? ==
-A [http://www.linuxfromscratch.org/lfs/view/6.8/ Linux From Scratch] root filesystem built on top of Aboriginal Linux.
+It's a [http://www.linuxfromscratch.org/lfs/view/6.8/ Linux From Scratch] root filesystem natively built on top of an Aboriginal Linux system image.
 One of the example native-build.sh control-images Aboriginal Linux provides is "lfs-bootstrap.hdc", which natively compiles and installs (almost) all of the LFS chapter 6 packages under the emulated development environment, according to the LFS build instructions.
@@ Line 31: / Line 31: @@
 The control image copies the read-only root filesystem into a writeable directory under /home, chroots into that, builds packages and installs them over the existing (busybox) versions, and then tars up the resulting filesystem.
-This provides a much more capable native build environment for the target.  Since Aboriginal Linux can already provide this for multiple targets, Funtoo uses this as its starting point, instead of starting from the minimal build environment and building/installing all of its own prerequisites.
+This provides a much more capable native build environment for the target.  Since Aboriginal Linux can already provide this for the supported targets, Funtoo uses this as its starting point instead of starting from the minimal build environment and building/installing all of its own prerequisites.
 = The plan of attack is as follows: =
-# Start from an LFS build, plus necessary stuff for Portage to run.  (Git, python...)
+# Start from an LFS build, plus necessary stuff for Portage to run.  (Git, python, portage tree, profile...)
 # Create a <tt>package.provided</tt> file for the local LFS system so that Portage doesn't complain of unsatisfied <tt>/var/db/pkg</tt> entries.
 # Use Portage to build a stage1 tarball to /tmp/stage1root.
-At this point, Funtoo has been bootstrapped and we can extend this approach to bootstrap Funtoo on any architecture.
+Once we have a stage 1 for the target, Funtoo has been bootstrapped and we can extend this approach to bootstrap Funtoo on any architecture.
 == Prerequisites ==
 # A smaller Portage tree to not eat up so much filesystem space. This has now been implemented. The script <tt>/root/git/funtoo-overlay/funtoo/scripts/generate-system-tree.py</tt> can be used to generate a system-only Portage tree.
 # A <tt>package.provided</tt> list of a current Funtoo system. This can be found at <tt>/root/git/funtoo-overlay/funtoo/scripts/stage3-provided.txt</tt>.
-== Update ==
+== Status ==
 The approach above didn't seem to correctly provide needed dependencies. Options at this point:
 # Bundle up what we have as a stage3 and see if Metro's steps are more successful at using it as a stage3 (we were trying simple emerge commands rather than the explicit metro steps for testing)
 # If package.provided is not working, simply copy <tt>/var/db/pkg</tt> from an existing stage3 for a massive injection of fake package information.
 [[Category:Labs]] [[Category:Projects]]

@@ Line 9: / Line 9: @@
 The resulting system can then boot under the emulator QEMU (or on appropriate hardware, if available) to provide a native development environment, eliminating the need for any further cross compiling.  You can wget, configure, make, and install additional source packages inside the emulator.
-Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://landley.net/aboriginal/downloads/presentation.pdf".
+Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu".
 == How do I use Aboriginal Linux? ==

← Older revision		Revision as of 00:52, 31 December 2011
Line 53:		Line 53:
	# If package.provided is not working, simply copy <tt>/var/db/pkg</tt> from an existing stage3 for a massive injection of fake package information.		# If package.provided is not working, simply copy <tt>/var/db/pkg</tt> from an existing stage3 for a massive injection of fake package information.

−	[[Category:Labs]][[Category:Projects]]	+	[[Category:Labs]] [[Category:Projects]]

← Older revision		Revision as of 23:16, 30 December 2011
Line 10:		Line 10:

	Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://landley.net/aboriginal/downloads/presentation.pdf".		Aboriginal Linux's web page is at "http://landley.net/aboriginal" and a long presentation about it is available at "http://landley.net/aboriginal/downloads/presentation.pdf".
		+
		+	== How do I use Aboriginal Linux? ==
		+
		+	Aboriginal Linux provides prebuilt native development environments for x86, x86-64, arm, mips, powerpc, and more, ready to run under the emulator. Install QEMU 1.0 or later, then go to http://landley.net/aboriginal/downloads/binaries", grab the appropriate system-image tarball, extract it, and run one of the following three shell scripts:
		+
		+	* ./run-emulator.sh - Boot to a shell prompt, with the simplest configuration: a read-only (squashfs) root filesystem with a tmpfs mounted on /home.
		+
		+	* ./dev-environment.sh - Boot to a shell prompt with a full development environment. This wrapper around run-emulator.sh adds a 2 gigabyte ext2 image on /home (persistent writeable space, in large amounts), and allocates 256 megabytes of physical memory for the emulator (enough to run gcc building complex packages). If distccd and the appropriate target's cross compiler are available in the host's $PATH, this script also configures the emulated environment to call out to the cross compiler via distcc, transparently moving the heavy lifting of compilation outside of the emulator.
		+
		+	* ./native-build.sh - Run an automated build. This requires a "control image", which is a squashfs filesystem the emulated system's init script mount on /mnt. The init script in the emulated root filesystem checks for /mnt/init and if that exists, it runs that instead of providing a shell prompt. (Actually it asks the user to press a key if they want a shell prompt, with a three second timeout.) See "http://landley.net/aboriginal/control-images" for details.
		+
		+	(You can build your own system images from source by following the instructins at "http://landley.net/aboriginal", but ReBootstrap does not require this.)

	= The plan of attack is as follows: =		= The plan of attack is as follows: =