gnomeos: We can now build gobject-introspection
This commit is contained in:
Colin Walters committed
1 parent
bd4fc401e4
commit
5b0084994e
22 files changed
+614
-298
No files matched your search
@@ -0,0 +1 @@
|
||||
SRC=git:git://git.gnome.org/glib
|
||||
@@ -0,0 +1 @@
|
||||
SRC=git:git://git.gnome.org/gobject-introspection
|
||||
@@ -0,0 +1,2 @@
|
||||
SRC=git:git://git.gnome.org/gtk-doc-stub
|
||||
COMPONENT=devel
|
||||
@@ -0,0 +1,2 @@
|
||||
SRC=svn:http://libarchive.googlecode.com/svn/trunk/libarchive-read-only
|
||||
CONFIGURE_OPTS=--disable-bsdtar --disable-bsdcpio
|
||||
@@ -0,0 +1,2 @@
|
||||
SRC=git:git://git.gnome.org/libxslt
|
||||
EXTRA_OECONF = "--disable-static"
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"name": "gnomeos-3.4",
|
||||
"architectures": ["i686"],
|
||||
"base": "yocto/gnomeos-3.4",
|
||||
|
||||
"components": [
|
||||
"gtk-doc-stub",
|
||||
"gobject-introspection",
|
||||
"glib"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,56 @@
|
||||
Overview
|
||||
--------
|
||||
|
||||
The build process is divided into two levels:
|
||||
|
||||
1) Yocto
|
||||
2) ostbuild
|
||||
|
||||
Yocto is used as a reliable, well-maintained bootstrapping tool. It
|
||||
provides the basic filesystem layout as well as binaries for core
|
||||
build utilities like gcc and bash. This gets us out of circular
|
||||
dependency problems.
|
||||
|
||||
At the end, the Yocto build process generates two tarballs: one for a
|
||||
base "runtime", and one "devel" with all of the development tools like
|
||||
gcc. We then import that into an OSTree branch
|
||||
e.g. "bases/gnomeos-3.4-yocto-i686-devel".
|
||||
|
||||
Now we also assume that you have ostree installed on the host build
|
||||
system via e.g. jhbuild or RPM if doing a cross build. The core
|
||||
ostbuild tool can then chroot into a checkout of the Yocto base, and
|
||||
start generating artifacts.
|
||||
|
||||
Each generated artifact is committed to an OSTree branch like
|
||||
"artifacts/gnomeos-3.4-i686-devel/libxslt/master/runtime". Then, a
|
||||
"compose" process merges together the individual filesystem trees into
|
||||
the final branches (e.g. gnomeos-3.4-i686-devel), and the process
|
||||
repeats.
|
||||
|
||||
ostbuild details
|
||||
-------------------
|
||||
|
||||
The simple goal of ostbuild is that it only takes as input a
|
||||
"manifest" which is basically just a list of components to build. A
|
||||
component is a pure metadata file which includes the git repository
|
||||
URL and branch name, as well as ./configure flags (--enable-foo).
|
||||
|
||||
There is no support for building from "tarballs" - I want the ability
|
||||
to review all of the code that goes in, and to efficiently store
|
||||
source code updates.
|
||||
|
||||
For GNOME, tarballs are mostly pointless - it's easy enough to just
|
||||
run autogen.sh. However there are two challenges:
|
||||
|
||||
1) Tarballs for modules which self-build-depend may include
|
||||
pre-generated files. For example - flex's tarball includes a
|
||||
generated .c file for the parser. For these, we can either move
|
||||
the module build to the Yocto level (thus giving a convenient way
|
||||
to pull in host files), or possibly add the ability to
|
||||
hardlink/copy in host binaries to ostbuild.
|
||||
|
||||
2) Tarballs which include translations pulled from a different
|
||||
location. For example - bison. For these, we basically have to
|
||||
maintain our own git repositories.
|
||||
|
||||
|
||||
@@ -1,104 +0,0 @@
|
||||
|
||||
Experimenting with multiple roots
|
||||
---------------------------------
|
||||
|
||||
$ mkdir gnomeos-chroot
|
||||
$ qemu-img create gnomeos.raw 2G
|
||||
$ mkfs.ext2 -F gnomeos.raw
|
||||
$ mount -o loop gnomeos.raw gnomeos-chroot
|
||||
$ debootstrap --arch=amd64 squeeze gnomeos-chroot
|
||||
|
||||
<http://wiki.debian.org/QEMU#Setting_up_a_testing.2BAC8-unstable_system>
|
||||
|
||||
Follow the steps for making a disk image, downloading the business
|
||||
card CD, booting it in QEMU and running through the installer. Note I
|
||||
used the QCOW format, since it is more efficient. Here are the steps
|
||||
I chose:
|
||||
|
||||
$ qemu-img create -f qcow2 debian.qcow 2G
|
||||
$ qemu-kvm -hda debian.qcow -cdrom debian-testing-amd64-businesscard.iso -boot d -m 512
|
||||
|
||||
Test that the image works after installation too, before you start
|
||||
modifying things below! Remember to remove the -cdrom and -boot
|
||||
options from the installation QEMU command. It should just look like
|
||||
this:
|
||||
|
||||
$ qemu-kvm -hda debian.qcow -m 512
|
||||
|
||||
|
||||
Modifying the image
|
||||
-------------------
|
||||
|
||||
You now have a disk image in debian.img, and the first partition
|
||||
should be ext4.
|
||||
|
||||
The first thing I did was mount the image, and move the "read only"
|
||||
parts of the OS to a new directory "r0".
|
||||
|
||||
$ mkdir /mnt/debian
|
||||
$ modprobe nbd max_part=8
|
||||
$ qemu-nbd --connect=/dev/nbd0 debian.qcow
|
||||
$ mount /dev/nbd0p1 /mnt/debian/
|
||||
$ cd /mnt/debian
|
||||
$ mkdir r0
|
||||
$ DIRS="bin dev etc lib lib32 lib64 media mnt opt proc root run sbin selinux srv sys tmp usr"
|
||||
$ mv $DIRS r0
|
||||
$ mkdir r0/{boot,var,home}
|
||||
$ touch r0/{boot,var,home}/EMPTY
|
||||
|
||||
Note that /boot, /home and /var are left shared; we create empty
|
||||
destination directories that will be mounted over. Now with it still
|
||||
mounted, we need to move on to the next part - modifying the initrd.
|
||||
|
||||
Then I started hacking on the initrd, making understand how to chroot
|
||||
to "r0". I ended up with two patches - one to util-linux, and one to
|
||||
the "init" script in Debian's initrd.
|
||||
|
||||
See:
|
||||
0001-switch_root-Add-subroot-option.patch
|
||||
0001-Add-support-for-subroot-option.patch
|
||||
|
||||
$ git clone --depth=1 git://github.com/karelzak/util-linux.git
|
||||
$ cd util-linux
|
||||
$ patch -p1 -i ../0001-switch_root-Add-subroot-option.patch
|
||||
$ ./autogen.sh; ./configure ; make
|
||||
|
||||
Now you have a modified "sys-utils/switch_root" binary. Let's next
|
||||
patch the initrd and rebuild it:
|
||||
|
||||
$ cd ..
|
||||
|
||||
Make a backup:
|
||||
|
||||
$ mkdir initrd
|
||||
$ cp /mnt/debian/boot/initrd.img-3.0.0-1-amd64{,.orig}
|
||||
|
||||
Unpack, and patch:
|
||||
|
||||
$ zcat /mnt/debian/boot/initrd.img-3.0.0-1-amd64 | (cd initrd; cpio -d -i -v)
|
||||
$ (cd initrd && patch -p1 -i ../0001-Add-support-for-subroot-option.patch)
|
||||
|
||||
Repack:
|
||||
|
||||
$ (cd initrd; find | cpio -o -H newc) | gzip > /mnt/debian/boot/initrd.img-3.0.0-1-amd64.new
|
||||
$ mv /mnt/debian/boot/initrd.img-3.0.0-1-amd64{.new,}
|
||||
|
||||
Unmount:
|
||||
|
||||
$ umount /mnt/debian
|
||||
|
||||
Running hacktree inside the system
|
||||
----------------------------------
|
||||
|
||||
This means that after booting, every process would be in /r0 -
|
||||
including any hacktree process. Assuming objects live in say
|
||||
/objects, we need some way for hacktree to switch things. I think
|
||||
just chroot breakout would work. This has the advantage the daemon
|
||||
can continue to use libraries from the active host.
|
||||
|
||||
Note there is a self-reference here (as is present in Debian/Fedora
|
||||
etc.) - the update system would at present be shipped with the system
|
||||
itself. Should they be independent? That has advantages and
|
||||
disadvantages. I think we should just try really really hard to avoid
|
||||
breaking hacktree in updates.
|
||||
|
||||
@@ -26,16 +26,21 @@ BRANCH=$1
|
||||
test -n "$BRANCH" || usage
|
||||
shift
|
||||
|
||||
ARCH=x86
|
||||
YOCTO_ARCH=x86
|
||||
MACHINE=i686
|
||||
|
||||
BUILDROOT="gnomeos-3.4-${MACHINE}-${BRANCH}"
|
||||
BASE="bases/yocto/${BUILDROOT}"
|
||||
|
||||
OSTREE_VER=$(cd $SCRIPT_SRCDIR && git describe)
|
||||
|
||||
BUILDDIR=$WORKDIR/tmp-eglibc
|
||||
|
||||
OSTREE_REPO=$WORKDIR/repo
|
||||
BUILD_TAR=$BUILDDIR/deploy/images/gnomeos-contents-$BRANCH-qemu${ARCH}.tar.gz
|
||||
BUILD_TAR=$BUILDDIR/deploy/images/gnomeos-contents-$BRANCH-qemu${YOCTO_ARCH}.tar.gz
|
||||
|
||||
BUILD_TIME=$(date -r $BUILD_TAR)
|
||||
|
||||
ostree --repo=${OSTREE_REPO} commit --skip-if-unchanged -s "Build from OSTree ${OSTREE_VER}" -b "gnomeos-yocto-$ARCH-$BRANCH" --tree=tar=${BUILD_TAR}
|
||||
ostree --repo=${OSTREE_REPO} diff "gnomeos-yocto-$ARCH-$BRANCH"^ "gnomeos-yocto-$ARCH-$BRANCH"
|
||||
ostree --repo=${OSTREE_REPO} commit --skip-if-unchanged -s "Build from OSTree ${OSTREE_VER}" -b "${BASE}" --tree=tar=${BUILD_TAR}
|
||||
ostree --repo=${OSTREE_REPO} diff "${BASE}"^ "${BASE}" || true
|
||||
cp ${OSTREE_REPO}/refs/heads/${BASE} ${OSTREE_REPO}/refs/heads/${BUILDROOT}
|
||||
Reference in new issue
Block a user