BeagleBoard demo image - Release r0

Would anyone be willing try out a new BeagleBoard image that I've created?

The next revision of the BeagleBoard image contains the following new
additions:

- Kernel 3.0.3 with a lot of fixes and with LCD support

- gstreamer-ti and ti-dmai stack

- U-boot with fixes for hub power

- Fixes to U-boot environment variables for LCD

- systemd for very fast boot (thanks to Koen)

- gnome desktop

- pulseaudio

- alsa

- midori

- gedit

- gstreamer plugins

Other features included:

- Ability to be Auto-flashed to NAND by holding the userbutton when u-boot
loads

- Ability to be rebuilt easily in SD card format

You can get this image in 2 simple ways:

1. Direct Download

http://www.beagleboard.org/~joelf/images/beagleboard-demo/Angstrom-beagleboard-gnome-image-eglibc-ipk-v2011.08-core-beagleboard-r0.img.gz

2. Rebuild from scratch

You can rebuild the image by following instructions at:
http://www.angstrom-distribution.org/building-angstrom

With the following differences:

1. Replace URLS in sources/layers.txt with ones similar to:

meta-angstrom,git://github.com/joelagnel/meta-angstrom.git,master,HEAD

meta-openembedded,git://github.com/joelagnel/meta-openembedded.git,master,HEAD

meta-texasinstruments,git://github.com/joelagnel/meta-texasinstruments.git,master,HEAD

openembedded-core,git://github.com/joelagnel/oe-core.git,HEAD

Personally, I like to follow the upstream work and just pull in
patches. If you tagged your trees per rX, that would be even easier.

What I did was:
$ cd ~/setup-scripts/sources/meta-angstrom
$ git remote add joel git://github.com/joelagnel/meta-angstrom.git
$ git remote update joel
$ git merge remotes/joel/master

I repeated that for meta-oe, meta-ti and oe-core.

Now, in the future, when I do a "./oebb.sh update", I'll be pulling in
the code from upstream, where I hope your patches for these releases
will land soon. When I get conflict errors, I'll be able to quickly
resolve them to take in the upstream versions. I will be able to
clean up my history with git rebase if desired at some point.

If you were going to recommend someone to use your fork by changing
layers.txt, I think you'd want to provide a similar fork for
setup-scripts and update layers.txt in it instead.

2. Build filesystem using Embedded by running the command:

bitbake beagleboard-validation-gnome-image

It might be a side effect of my approach (bringing in newer community
code), but I started getting errors with conf/bblayers.conf and
conf/site.conf being old. I was able to fix conf/bblayers.conf by
merging in Koen's latest and I was able to manually fix conf/site.conf
by adding:

SCONF_VERSION = "1"

FWIW, I'm still waiting on an updated pull request addressing the feedback I gave (mostly licensing issues).

Would anyone be willing try out a new BeagleBoard image that I've created?

The next revision of the BeagleBoard image contains the following new
additions:

- Kernel 3.0.3 with a lot of fixes and with LCD support

- gstreamer-ti and ti-dmai stack

- U-boot with fixes for hub power

- Fixes to U-boot environment variables for LCD

- systemd for very fast boot (thanks to Koen)

- gnome desktop

- pulseaudio

- alsa

- midori

- gedit

- gstreamer plugins

Other features included:

- Ability to be Auto-flashed to NAND by holding the userbutton when u-boot
loads

- Ability to be rebuilt easily in SD card format

You can get this image in 2 simple ways:

1. Direct Download

http://www.beagleboard.org/~joelf/images/beagleboard-demo/Angstrom-beagleboard-gnome-image-eglibc-ipk-v2011.08-core-beagleboard-r0.img.gz

2. Rebuild from scratch

You can rebuild the image by following instructions at:
http://www.angstrom-distribution.org/building-angstrom

With the following differences:

1. Replace URLS in sources/layers.txt with ones similar to:

meta-angstrom,git://github.com/joelagnel/meta-angstrom.git,master,HEAD

meta-openembedded,git://github.com/joelagnel/meta-openembedded.git,master,HEAD

meta-texasinstruments,git://github.com/joelagnel/meta-texasinstruments.git,master,HEAD

openembedded-core,git://github.com/joelagnel/oe-core.git,HEAD

Personally, I like to follow the upstream work and just pull in
patches. If you tagged your trees per rX, that would be even easier.

What I did was:
$ cd ~/setup-scripts/sources/meta-angstrom
$ git remote add joel git://github.com/joelagnel/meta-angstrom.git
$ git remote update joel
$ git merge remotes/joel/master

I repeated that for meta-oe, meta-ti and oe-core.

Now, in the future, when I do a "./oebb.sh update", I'll be pulling in
the code from upstream, where I hope your patches for these releases
will land soon. When I get conflict errors, I'll be able to quickly
resolve them to take in the upstream versions. I will be able to
clean up my history with git rebase if desired at some point.

If you were going to recommend someone to use your fork by changing
layers.txt, I think you'd want to provide a similar fork for
setup-scripts and update layers.txt in it instead.

2. Build filesystem using Embedded by running the command:

bitbake beagleboard-validation-gnome-image

Are you certain it is beagleboard-validation-gnome-image and not
beagleboard-gnome-image?

Hi Koen,

I had already submitted a gnome v3 patchset to oe-core addressing all
the licensing issues. I've yet to work on the mplayer patches I
already submitted but then again mplayer still throws build errors.

thanks,
Joel

Oops, will correct that. I think it is better to document it in a
README instead of me (re-)creating these everytime.

Thanks,
Joel

Hi Jason,

Thanks for the feedback, I will make it a point to incorporate some or
all of them in subsequent releases.

Regards,
Joel

..

If you were going to recommend someone to use your fork by changing
layers.txt, I think you'd want to provide a similar fork for
setup-scripts and update layers.txt in it instead.

2. Build filesystem using Embedded by running the command:

bitbake beagleboard-validation-gnome-image

It might be a side effect of my approach (bringing in newer community
code), but I started getting errors with conf/bblayers.conf and
conf/site.conf being old. I was able to fix conf/bblayers.conf by
merging in Koen's latest and I was able to manually fix conf/site.conf
by adding:

I would think a cleaner approach is to provide a drop in replacement
for layers.txt which I can included for download in the same location
as the image than providing more instructions on cloning setup scripts
and having to maintain a separate setup scripts repository.

Thanks,
Joel

And you had feedback on that, so please send a v4 addressing it or you patches will never go upstream

FWIW, I'm still waiting on an updated pull request addressing the feedback I
gave (mostly licensing issues).

Hi Koen,

I had already submitted a gnome v3 patchset to oe-core addressing all
the licensing issues.

And you had feedback on that, so please send a v4 addressing it or you patches will never go upstream

Sure, I just figured my email filters are all messed up just for
oe-core, I have corrected it so I should not miss any more emails from
now.

Thanks!
Joel

[…]

I had already submitted a gnome v3 patchset to oe-core addressing all
the licensing issues.

How are GNOME packages divided up between oe-core and meta-oe? I see
`recipes-gnome` in both.

[…]

Thanks,

Paul

That's a matter of debate currently, but my stance is that everything above glib-2.0 shouldn't be in oe-core. Realizing that will involve sitting people down and redo *all* non-BSP layers.