This is a small Django-based web application that provides a way to manage an index of OpenEmbedded metadata layers for use on top of OE-Core.
There are two main methods of setting up this application - within a set of Docker containers, or standalone. The Docker-based setup is more suited for production whereas standalone is a bit easier for development.
To use layerindex-web hosted within Docker containers, refer to docker/README keeping in mind you'll need to set up Docker properly as part of the setup process. Once you've run through those instructions you'll need to return to this document and follow the instructions in the section "Database Setup" below.
In order to run this application standalone you will need:
Example virtualenv-based setup for the above:
Python's virtualenv provides an easy way to isolate the python dependencies of applications such as the layer index. Here's an example of setting up a virtualenv for the layer index that's particularly useful for development. (This assumes a Debian-based distribution, adjust accordingly for other distros).
Install required host distro packages (some of these are required by pip to build the dependencies; it's also assumed you want MariaDB as the database backend):
sudo apt-get install virtualenv libmariadb-client-lgpl-dev build-essential python3-dev libjpeg-dev libz-dev libfreetype6-dev mariadb-server rabbitmq-server
Work around path issues (you may not need this):
sudo ln -s /usr/bin/mariadb_config /usr/bin/mysql_config
Create a Python 3 virtualenv (path can be anywhere you like):
virtualenv -p python3 /path/to/desired/venv
Activate the virtualenv:
. /path/to/desired/venv/bin/activate
Install requirements:
pip install -r requirements.txt
Configuration and running:
Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and other settings specific to your installation. Ensure you set LAYER_FETCH_DIR to an absolute path to a location with sufficient space for fetching layer repositories. Modify RABBIT_BROKER and RABBIT_BACKEND to reflect the settings used by your RabbitMQ server.
Run the following commands within the layerindex-web directory to initialise the database:
python3 manage.py migrate python3 manage.py createsuperuser
You can test the web application locally by setting DEBUG = True in settings.py and running the following:
python3 manage.py runserver
Then visit http://127.0.0.1:8000/layerindex/ with your browser. As with all Django applications there is an admin interface available at http://127.0.0.1:8000/admin/ also. The initial login and password will be those you entered in the step above when creating an admin account.
NOTE: This local server should only be used for testing - for production you need to use a proper web server and have DEBUG set to False (or use the Docker-based setup).
3.1. In order to process asynchronous tasks like sending email, you will need to run a Celery worker:
celery -A layerindex.tasks worker --loglevel=info
Once the application is running you'll need to do a bit of further setup within it:
You'll need to add at least the openembedded-core layer to the database, or some equivalent that contains conf/bitbake.conf for the base system configuration. To add this, follow these steps:
1.1. With the server running, go to the main page ( http://127.0.0.1:8000/admin/ or equivalent depending on your setup) and click on the "Log in" button on the top right. Use the login/password for the admin account you added previously.
1.2. Click on the "Submit Layer" button in the top right and enter the details for the core layer. To use the real openembedded-core layer, use these values:
Layer name: openembedded-core
Layer type: Base
Summary: Core metadata
Description: Core metadata
Repository URL: git://git.openembedded.org/openembedded-core
Repository subdirectory: meta
Once you have filled in the required values, click on the
"Submit Layer" button.
NOTE: The name of the layer must be "openembedded-core",
unless you change CORE_LAYER_NAME in settings.py to match
whatever alternative name you use here.
2.3. The layer has been added but is not yet published. (For the public index this provides some protection against spam and malformed entries.) To publish it, click on the orange number next to your login name at the top right, click on the newly added layer entry, and then click on "Publish Layer".
If you need to support multiple branches of OpenEmbedded/BitBake where some require Python 2.x and others require Python 3.x, then you will need to set up "Python environment" records through the admin interface to correspond to these so that the right Python version gets used to parse the branch, and then set the "Update environment" field on each branch record to point to the appropriate environment. If you're using virtualenv you will need separate virtual environments set up for Python 2 and 3 which you should point to in the Python environment record.
Set the site name (as displayed in the top bar and page titles) by going into the admin interface (http://127.0.0.1:8000/admin/ or equivalent), clicking on "Sites" at the bottom, and editing the first entry, setting "Display name" to the desired name.
You may wish to customise some of the page templates to suit your installation, in particular:
On a regular basis you need to run the update script:
path/to/layerindex/update.py
This will fetch all of the layer repositories, analyse their contents and update the database with the results. Run the script with --help for further information on available options.
This application uses Django's migrations functionality to allow changes in the database structure whilst preserving existing data. When upgrading with an existing database, you just need to invoke the migration command.
If you're migrating from a version prior to the Django 1.8 upgrade, you need to use the following command so that the initial migration (which takes care of creating the database structure and initial data) is skipped:
python3 manage.py migrate --fake-initial
Otherwise, you can just run the plain migration command:
python3 manage.py migrate
The Layer index optionally provides a means to index OE-Classic on a one-off import basis and then compare what was there to what you have now in the indexed layers (with some graphs showing how much of it has been migrated/superseded). If you want to enable this, do the following:
From the admin interface, create a Branch record with the following values:
Clone OE-Classic somewhere locally on the machine running the layer index:
git clone git://git.openembedded.org/openembedded
Clone a bitbake somewhere locally and check out the 1.12 branch:
git clone git://git.openembedded.org/bitbake -b 1.12
Run import_classic.py, specifying the path to OE-Classic and the bitbake you checked out:
layerindex/tools/import_classic.py /path/to/bitbake112 /path/to/oeclassic
Update the migration status of OE-Classic recipes based on other layers in the database:
layerindex/tools/update_classic_status.py
If you refresh the main page of the website, the OE-Classic data should now show up at the bottom of the branch drop-down menu. On a periodic basis you can repeat the last step to update the migration status in case new recipes are brought across (or replacements are created). Users with sufficient permissions can also manually update the migration status on the OE-Classic recipe detail pages within the website, which is useful for example when there's a replacement recipe in another layer that doesn't have the same name, so the update_classic_status.py script wouldn't be able to pick it up.
The Layer Index also provides optional functionality to enable comparison with other distributions (currently RPM-based only) in a similar manner to OE-Classic comparison documented above. To set this up you need to perform the following steps:
From the admin interface, set up the appropriate entries:
1.1. Create a Branch with the following values: - Bitbake branch: - Enable updates: NOT enabled - Comparison: enabled
1.2. Create a Layer. Typically this would have the same name as the branch although that is not a requirement. The "Comparison" checkbox should be ticked. If the packages are in separate repositories (one per package, as is typical in RPM-based distributions such as Fedora) then in order to make the links through to files work correctly you may need to use repository web interface URLs similar to these:
Repository web interface tree base URL:
https://github.com/organisationname/%pathelement[0]%/tree/master/%pathelement[1:]%
Repository web interface file base URL:
https://github.com/organisationname/%pathelement[0]%/blob/master/%pathelement[1:]%
1.3. Create a LayerBranch to link the Branch and Layer that you created in the previous steps. You don't need to enter anything special here.
Run the import script, specifying the branch and layer names and the path to the base of the packages (where each subdirectory contains a package, notably a spec file describing the package):
layerindex/tools/import_otherdistro.py import-pkgspec
Update the comparison status of recipes based on layers in the database:
layerindex/tools/update_classic_status.py -l -b
Optionally enable the Update button in the UI by setting COMPARISON_UPDATE in settings.py to map each other distro branch to the command that should be run in the background when the button is pressed. For example:
COMPARISON_UPDATE = [ { 'branch_name': 'otherlinux', 'update_command': 'layerindex/tools/import_otherdistro.py import-pkgspec otherlinux otherlinux /path/to/pkgs -u %update%; layerindex/tools/update_classic_status.py -b otherlinux -l otherlinux -u %update%', }, ]
If you refresh the main page of the website, the other distro data should now show up at the bottom of the branch drop-down menu. On a periodic basis you can repeat steps 2 and 3 to refresh the data as changes occur on both sides. Users with sufficient permissions can also manually update the migration status on the other distro recipe detail pages within the website, which is useful for example when there's an equivalent recipe in another layer that doesn't have the same name, so the update_classic_status.py script wouldn't be able to pick it up.
If you want to show links to additional upstream pages associated with packages in the other distro, you can add "Layer recipe extra URL" entries for each type of link you want to be shown. For example, Fedora provides a summary page for each package - acl's one is at https://apps.fedoraproject.org/packages/acl, so you would create a Layer Recipe Extra URL entry with the template URL "https://apps.fedoraproject.org/packages/%pn%" and then links would be shown for this under the detail page for each package in the other distro. If you have the rrs application enabled the link will also be shown in the "Distros" section of the maintenance detail page for the covering recipe.
The code for this application is maintained by the Yocto Project.
The latest version of the code can always be found here:
http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/
Contributions are welcome. Please send patches / pull requests to [email protected] with '[layerindex-web]' in the subject.
This application is based upon the Django project template, whose files are covered by the BSD license and are copyright (c) Django Software Foundation and individual contributors.
Bundled Bootstrap (including Glyphicons) is redistributed under the MIT license.
Bundled jQuery is redistributed under the MIT license.
Bundled uitablefilter.js is redistributed under the MIT license.
Bundled nv.d3.js is redistributed under the Apache License 2.0.
Bundled d3.js is redistributed under the BSD License.
All other content is copyright (C) 2013-2018 Intel Corporation and licensed under the MIT license (unless otherwise noted) - see COPYING.MIT for details.
Content type
Image
Digest
Size
231 MB
Last updated
over 6 years ago
docker pull windriver/layerindex