Toaster

Toaster is a Web-based interface to the Bitbake build system and the Poky distribution inside the Yocto Project. This project was formely known as Web Hob / Webhob / webhob, and you may still find references to the old name in the documentation.

General discussion about Toaster happens on a dedicated mailing list: https://lists.yoctoproject.org/listinfo/toaster

Project planning is available below, are the design documents we follow.

User interface

The design of the user interface takes place in iterations, and most recent designs supersede older ones. Here is a set of links to design documentation.

• Web_Hob_design_project_with_T&T - the latest user interface design
• Visualisations - an inventory of data visualisations we aim to include in the first release of Toaster
• File:WH roadmap.pdf - the roadmap for Toaster development produced by the London-based agency Tobias&Tobias
• File:Multiuser support in Web Hob.pdf - different design approaches to handle multi-user scenarios
• File:Web Hob content structure.pdf - Toaster information architecture, as it came out from the design project with Tobias&Tobias
• File:Web Hob 1.5 content structure v0.2.pdf - Information architecture for the first release of Toaster

Toaster clickable prototype

• A web-based prototype of the Toaster user interface

Old design documents

• [[Toaster_Design]]
• A preliminary design project by Jim Kosem

Project Planning

We plan to develop Toaster functionality in stages. Each stage should match with an Yocto Project release.

YP 1.5 release

• Toaster will offer features to record and analyze bitbake runs, where a bitbake run is an invocation of bitbake to a certain target.
• Toaster will offer ways to inspect the system image contents generated by running a Poky target that results in a disk image.

[Toaster Bugzilla feature list]

Architecture and component design

We are planning the capabilities of Toaster based on evolutive stages of implementation, using community feedback on each stage to plan, design and implement a set of capabilities for the next stage. In the first stage, synchronized with the planning of Yocto 1.5, we'll implement a build analysis / image inspection module.

Toaster is designed as a collection of components that will run independently performing isolated functions. The interfaces between components are documented on this wiki as to ease interoperability with newer components. From design phase, we've taken care to account for further expansion needs, and account for scalability problems.

• [[ Toaster general architecture ]]

• Data store investigation results and choices

• [[ Toaster source code repository details ]]

• Django models

• REST API Contracts

• Bugzilla feature list

Installation and Running

Using the master branch

You need this stuff ready:

• Django 1.5; easiest way is to install system wide with pip install django==1.5
• Make sure that port 8000 and 8200 are free, i.e. no servers on them

To get it up and running:

• clone the master tree: http://git.yoctoproject.org/git/poky
• set up a build as normal: source poky/oe-init-build-env
• at this point edit local.conf, or layers, etc.
• start Toaster system: source toaster start
• run builds normally: bitbake core-image-minimal
• to see the web interface: xdg-open http://localhost:8000/
• to stop Toaster: source toaster stop

Using the Dora + Toaster release (part of Yocto Project 1.5)

You need this stuff ready:

• Django 1.4.5; easiest way is to install system wide with pip install django==1.4.5
• Make sure that port 8000 and 8200 are free, i.e. no servers on them

To get it up and running:

• checkout the Dora + Toaster release tree: http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dora-toaster
• set up a build as normal: source poky/oe-init-build-env
• at this point edit local.conf, or layers, etc.
• start Toaster system: source toaster start
• run builds normally: bitbake core-image-minimal
• to see the web interface: xdg-open http://localhost:8000/
• to stop Toaster: source toaster stop

Bitbake extra options

This is an overview of extra options needed for Bitbake. These should be automatically added by Toaster in a conf/toaster.conf file that is enabled when the system starts through the toaster command.

The gritty details are here:

Toaster needs the toaster bbclass enabled in Bitbake in order to record target image package information. INHERIT += "toaster"

This enables the toaster bbclass in Bitbake, needed to record target image package information.

INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"

This enables buildhistory in Bitbake, needed to record target image package information. This last command is not strictly needed, yet without it buildhistory will not work right in it's own right.

A bunch of files are created and used under the build/ directory:

• toaster.sqlite - the database file
• toaster_web.log - the log file of the web server
• toaster_ui.log - the log file of the ui component
• .toastermain.pid - contains the pid of the web server
• .toasterui.pid - contains the pid of the DSI data bridge
• bitbake-cookerdaemon.log - the log file of the bitbake server

Testing

Documentation and results related to Toaster Quality Assurance.

• Toaster testing plan

Old page content

This page is about the Web Hob project. Web Hob is a web-based interface to the Yocto Project.

General discussion about Web Hob happens on a dedicated mailing list: https://lists.yoctoproject.org/listinfo/webhob

There have been 2 main pieces of work related to Web Hob so far:

• A design project with the London-based agency Tobias & Tobias
• A preliminary design project by Jim Kosem

Web Hob information architecture

This document represents the content structure of the Web Hob application.

File:Web Hob content structure.pdf

Different approaches to multi-user workflows

This document outlines the different approaches we have uncovered so far to facilitate multi-user and team work with Web Hob.

• File:Multiuser support in Web Hob.pdf

Visualisations index

The build analysis functionality in Web Hob will include several graphical presentations of build data. The first step to design them is listing them all.