BitBake Team 2004, 2005, 2006 Chris Larson Phil Blundell Руководство выпущено под лицензий c указанием авторства (Creative Commons Attribution License). Ознакомиться с лицензией можно по ссылке http://creativecommons.org/licenses/by/2.5/ или отправив письмо в Creative Commons по адресу: 559 Nathan Abbott Way, Stanford, California 94305, USA.

BitBake это инструмент для работы с метаданными и выполнения задач. Во многом он схож с GNU make и другими существующествующими инструментами сборки. При его разработке многие идеи были почерпнуты из системы управления пакетами portage, используемой в дистрибутиве Gentoo Linux. BitBake - фундамент проекта OpenEmbedded, используемого для сборки и сопровождения множества встраиваемых дистрибутивов Linux, включая такие как OpenZaurus и Familiar.

До BitBake ни одна из систем сборки не удволетворяла должным образом растущим потребностям встраиваемых дистрибутивов Linux. А в системах сборки традиционных дистрибутивов Linux отсутствует необходимый функционал для сборки и сопровождения. Кроме этого ни одна из распрастраненных специализированных систем сборки (buildroot system), не была достаточно масштабируемой и удобной в сопровождении. Некоторые из важных требований предъявленных к BitBake: Поддержка кросс-сборки. Поддержка зависимостей между пакетами (во время сборки для целевой платформы, во время сборки на родной платформе,и во время выполнения). Поддержка выполнения различных задач в пакете, включая получение исходных кодов, их распаковка, наложение патчей, настройка, и прочее. Независимость от дистрибутива Linux (как для платформы сборки, так и для целевой платформы). Независимость от архитектуры платформы сборки Поддержка различных целевых платформ и платформ сборки (включая cygwin, BSD и другие). Отсутствие привязок к корневой файловой системе ОС. Выбор необходимых метаданных в зависимости от целевой платформы, операционной системы, дистрибутива и архитектуры. Простое добавление дополнительных метаданных и пакетов. Простое взаимодействие между проектами которые используют BitBake для своих сборок. Предоставление механизма разделения общих метаданных между пакетами. BitBake удволетворяет не только этим требованиям, но и многим другим, так как высокая гибкость и широкие возможности всегда были на первом месте. В результате BitBake хорошо расширяем, позволяет встраивать код на Python и выполнять множество различных задач.

Метаданные BitBake делятся на 3 класса: Файлы настройки .bb файлы Классы Далее описывается синтаксис операций поддерживаемых в метаданных Bitbake с указанием области действия (если она ограничена) и приводятся примеры использования операций в метаданных BitBake.

VARIABLE = "value" В этом примере, после выполнения операции переменная VARIABLE будет иметь значение value.

BitBake поддерживает использование в значениях ссылок на другие переменные, через синтаксис аналогичный в скриптах shell A = "aval" B = "pre${A}post" В результате выполнения операций переменная A будет иметь значение aval, а B будет иметь значение preavalpost.

A ?= "aval" Если переменная A до вызова этой операции уже имела значение, то ее значение не изменится. Если же переменная A не имела значения до вызова этой операции, то переменная A будет иметь значение aval. Заметим что, если имеется множественое использование операции, сработает только первая из них.

A ??= "somevalue" A ??= "someothervalue" Если переменная A до вызова этой операции уже имела значение, то ее значение не изменится. Если переменная A не имела значения до вызова этой операции, то переменная A будет иметь значение someothervalue. Это "ленивая" версия операции ?=, в случае множественного использования операции, срабатывает последняя из них.

:= в результате выполнения операции, значение переменной, заменяется. T = "123" A := "${B} ${A} test ${T}" T = "456" B = "${T} bval" C = "cval" C := "${C}append" В примере, в результате выполнения операций перменнаяA будет иметь значение test 123, переменная B будет иметь значение 456 bval, а переменная C будет иметь значение cvalappend.

B = "bval" B += "additionaldata" C = "cval" C =+ "test" В результате выполнения, B будет иметь значение bval additionaldata, а C будет иметь значение test cval.

B = "bval" B .= "additionaldata" C = "cval" C =. "test" В результате выполнения, B будет иметь значение bvaladditionaldata, а C будет иметь значение testcval. В отличии от постфиксной (+=) и префиксной (=+) операций добавления, эти операции не добавляют пробел.

OVERRIDES это список разделенный :, где каждый элемент указывает на условия которые будут проверяться. К примеру если у вас есть переменная обусловлена arm, и arm присутствует в OVERRIDES, то более обусловленная версия переменной arm будет использована вместо менее необусловленной. К примеру: OVERRIDES = "architecture:os:machine" TEST = "defaultvalue" TEST_os = "osspecificvalue" TEST_condnotinoverrides = "othercondvalue" В результате переменная TEST будет содержать osspecificvalue, так как условие os присутствует в списке OVERRIDES.

BitBake так же поддерживает условные постфиксные и префиксные операции над переменными с использованием списка OVERRIDES. К примеру: DEPENDS = "glibc ncurses" OVERRIDES = "machine:local" DEPENDS_append_machine = " libmad" В результате выполнения переменная DEPENDS будет иметь значение glibc ncurses libmad.

Деректива include, указывает BitBake обработать указанный вами файл и вставить его в необходимом месте, она похожа на такую же дерективу в make. Но однако, если в директиве include указан относительный путь, BitBake будет искать первое вхождение в BBPATH.

В отличии от директивы include, require вызывает ошибку ParseError если файл для включения не найден. Во всем остальном она точно такая же как деректива include.

DATE = "${@time.strftime('%Y%m%d',time.gmtime())}" В результате DATE будет содержать текущую дату.

Примечание: Эта возможность поддерживается только в .bb и .bbclass файлах. do_mytask () { echo "Hello, world!" } Определение аналогично установке переменной, только в результате вызова задачи будет исполнен shell сценарий. python do_printdate () { import time print time.strftime('%Y%m%d', time.gmtime()) } Аналогично выше приведенному определению задачи, но добавление флага python указывает BitBake, для запуска надо воспользоваться интерпретатором python.

Примечание: Эта возможность поддерижвается только для .bb и .bbclass файлов. def get_depends(bb, d): if bb.data.getVar('SOMECONDITION', d, True): return "dependencywithcond" else: return "dependency" SOMECONDITION = "1" DEPENDS = "${@get_depends(bb, d)}" В результате DEPENDS будет содержать dependencywithcond.

Переменные могут быть ассоциированы с флагами для сохранения дополнительной информации о переменной. Некоторые флаги используются самим bitbake, но они их можно использовать и помимо этого, если вам это необходимо. Операции описанные выше работают с флагами как с обычными переменными. К примеру: VARIABLE[SOMEFLAG] = "value" В результате, к пермеенной VARIABLE добавляется флаг SOMEFLAG со значением value.

Примечание: Эта возможность поддерживается только в .bb и .bbclass файлах. Деректива inherit указывает функционал каких классов будет использоваться в .bb файле. Это позволяет организовать простейшую форму наследования. К примеру вы легко можете отделить задачи использующие при сборке пакета autoconf и automake в отдельный bbclass, при подключении которого пакеты смогут использовать их. Указанный bbclass ищется по маске classes/filename.bbclass, в списке путей BBPATH, где filename это имя класса который наследуется.

Примечание: Эта возможность поддерживается только в .bb и .bbclass файлах. В BitBake, каждый шаг который может быть запущен в файле .bb является задачей. Команда addtask добавляет новые задачи (должны быть определены как python исполняемые метаданные и должны начинаться с do_) доступные для исполенния и описывает зависимости между задачами. python do_printdate () { import time print time.strftime('%Y%m%d', time.gmtime()) } addtask printdate before do_build В этом примере определяется задача на python и определяется зависимость от задачи do_build (задача по умолчанию). Если кто-нибудь вызовет задачу do_build, то в результате сначала выполнится задача do_printdate, а затем do_build.

Примечание: Эта возможность доступна только в .bb и .bbclass файлах. BitBake позволяет устанавливать обработчки событий. События могут возникать во время различных операций, таких как начало обработки .bb файла, старта указаной задачи, неудачного завершения задачи, удачного завершения задачи и во многих других случаях. Это позволяет легко реализовывать такие вещи как email уведомения при ошибках сборки. addhandler myclass_eventhandler python myclass_eventhandler() { from bb.event import NotHandled, getName from bb import data print "The name of the Event is %s" % getName(e) print "The file we run for is %s" % data.getVar('FILE', e.data, True) return NotHandled } Этот обработчик событий вызывается каждый раз как просходит событие. Для обращения к событию определена глобальная переменная e. e.data содержит копию bb.data. При помощи функции getName(e) можно узнать имя возникшего события. Таким образом выше приведенный обработчик выводит имя события и значение переменной FILE.

Для поддержки возможности создания множества вариантов сборки пакета используя один файл рецепт, в Bitbake имеются два специальных расширения. Первое это BBCLASSEXTEND. Эта переменная содержит список разделенных пробелами классов, для наследования в каждом из вариантов сборки рецепта. К пример, если присвоить: BBCLASSEXTEND = "native" то в результате станет доступен еще один вариант сборки. Этот вариант сборки будет дополнительно наследовать класс "native". Второе расширение это BBVERSIONS. Это расширение позволяет при помощи одного рецепта собирать множество версий пакета при помощи одного файла-рецепта, а так же позволяет указывать использовать условные операции (через OVERRIDES) для одной из версий или же для заданого дапазона версий: BBVERSIONS = "1.0 2.0 git" SRC_URI_git = "git://someurl/somepath.git" BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+" SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1" Так же стоит отметить, что имя диапазона по умолчанию совпадает с оригинальным именем рецепта, полученным от OE. К примеру файл рецепт foo_1.0.0+.bb будет иметь имя диапазона версий будет 1.0.0+ Это позволяет использовать имя диапазона не только через условные операции, но и делает доступным использование его в путях поиска file:// (FILESPATH) через переменную BPV .

Начиная с версии 1.7.x Bitbake работает с метаданными на уровне задач, что позволяет использовать множество потоков для их выполнения. Из-за этого требуется надежный метод разрешения зависимостей задачи перед ее выполнением.

Когда зависимости задаются внутри .bb файла, то обработка осуществляется описаной выше дерективой addtask.

DEPENDS описывает зависимости необходимые на стадии сборки. Флаг 'deptask' у задач может быть использован для указания, какая задача у каждой зависимости из DEPENDS должна быть завершена до того как задача может быть запущена. do_configure[deptask] = "do_populate_staging" это указывает, что задача do_populate_staging у каждой зависимости в списке DEPENDS должна быть завершена до того как задача do_configure будет запущена.

RDEPENDS описывает зависимсти необходимые на стадии выполнения. Флаг 'reptask' у задач может быть использован для указания, какая задача у каждой зависимости из RDEPENDS должна быть завершена до того как задача может быть запущена. do_package_write[rdeptask] = "do_package" это указывает, что задача do_package у каждой зависимости в RDEPENDS должна быть завершена, до того как задача do_package будет запущена.

Флаг 'recdeptask' у задач может быть использован для указания, какая задача у каждой зависимости из DEPENDS должна быть завершена до того как задача может быть запущена. Этот флаг добавляет рекурсию, так что задачи зависимости из DEPENDS каждой зависимости из DEPENDS должен так же удволетворять условию.

Флаг 'recrdeptask' у задач может быть использован для указания, какая задача у каждой зависимости из RDEPENDS должна быть завершена до того как задача может быть запущена. Этот флаг добавляет рекурсию, так что задачи зависимости из RDEPENDS каждой зависимости из RDEPENDS должен так же удволетворять условию.

Флаг 'depends' для задач является более простой формой задать зависимости между задачами, чем использование DEPENDS или RDEPENDS. do_patch[depends] = "quilt-native:do_populate_staging" это указываеть что задача do_populate_staging пакета quilt-native должна завершиться до того как будет запущена задача do_patch.

Первым классом метаданных в BitBake являются метаданные настройки. Эти метаданные глобальны и влияют на все пакеты и запускаемые задачи. При старте Bitbake сначала ищет в текущем рабочем каталоге опциональный файл настройки "conf/bblayers.conf" В этом файле ищется переменная BBLAYERS содержащая список 'слоев'-каталогов разделенных пробелами. В каждом каталоге из этого списка ищется и разбирается файл "conf/layer.conf" с установкой значения пременной LAYERDIR в каталог где найден файл. Эти файлы создаются для автоматической установки перменной BBPATH и корректной устрановки других переменных используя текущий рабочий каталог, как каталог сборки. Bitbake ожидает, что файл 'conf/bitbake.conf' находится в одном из каталогов списка BBPATH. По умолчанию этот файл включает в себя дерективы подключения остальных метаданных (обычно это файлы специфичные для архитектуры, платформы, локальных настроек и тому подобные) В файлах .conf разрешено только определение перменных и дерективы include.

Как было отмечено раньше классы BitBake реализуют простейший механизм наследования. В введении в метаданные, указано что их обработка начинается при встрече дерективы inherit, и моут быть размещены в classes подкаталоге каталогов из списка BBPATH.

BitBake (.bb) файл это логическая еденица используемая для запуска задач. Обычно они используются для сборки пакетов и могут зависеть друг от друга. Эти файлы ищутся при помощи перменной BBFILES, которая представляет из себя список .bb файлов, разделенных пробелами. В списке поддерживаются маски, к примеру recipes/*/*.bb.

BitBake предоставляет загрузку файлов через процедуру называемую получение. SRC_URI обычно указывает BitBake какие файлы должны быть запрошены. Следущие разделы описывают какие существуют механизмы загрузки и какими параметрами они обладают. Каждый механизм загрузки обладает своим набором переменных и параметров в URI пары ключ и значение которых разделяются при ;. Вид переменных и параметров определяются механизмом загрузки, хотя BitBake пытается сохранять их постоянным среди механизмов загрузки.

URN механизма загрузки локальных файлов file. Путь может быть абсолютным или относительным. Если путь относительно, то используются переменные FILESPATH и FILESDIR для поиска подходящего файла. Дополнительно на поиск может влиять переменная OVERRIDES. Путь может указывать как на отдельные файлы, так и на каталоги. SRC_URI= "file://relativefile.patch" SRC_URI= "file://relativefile.patch;this=ignored" SRC_URI= "file:///Users/ich/very_important_software"

URN механизма загрузки из CVScvs. Этот механизм загрузки использует перменные DL_DIR, SRCDATE, FETCHCOMMAND_cvs, UPDATECOMMAND_cvs. DL_DIRS указывает где размещается временный каталог для полученния данных, SRCDATE указывает дату которая используется при получении данных (специальное значение "now" указывает на обновление при каждой сборке), FETCHCOMMAND и UPDATECOMMAND указывают на команды, которые должны быть использованы для получения данных из CVS или их обновления. Поддерживаемые параметры это module, tag, date, method, localdir, rsh. Параметр module указывает какой модуль необходимо получить, tag описывает какой CVS TAG должен использваться при получении, по умолчанию он пуст. Пераметр date может быть указана для перекрытия переменной SRCDATE в настройках. Специальное значение "now" будет вызывать обновление при каждой сборке. Параметр method по умолчанию установлен в pserver, Если ext используется, то rsh параметр вычисляется и выставляется в качестве значения переменной CVS_RSH. Параметр localdir используется для получения даных в каталог относительно переменной CVSDIR>. SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"

URN для HTTP/FTP http, https и ftp. Этот механизм загрузки использует перменные DL_DIR, FETCHCOMMAND_wget, PREMIRRORS, MIRRORS. Переменная DL_DIR определяет куда будут сохраняться полученные файлы, переменная FETCHCOMMAND указывает какой командой будет осуществляться получение. ${URI} и ${FILES} будут замененяются на uri и имя файла которого надо получить. Переменная PREMIRRORS указывает откуда сначала стоит попробовать получить файл. В случае если произошла неудача, то проверяются все источники из MIRRORS. Поддерживается только один параметр, это md5sum. После получения осуществляется вычисление md5sum файла и суммы сравниваются. SRC_URI = "http://oe.handhelds.org/not_there.aac;md5sum=12343" SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac;md5sum=1234" SRC_URI = "ftp://you@oe.handheld.sorg/home/you/secret.plan;md5sum=1234"

на данный момент НЕ поддерживается

URN механизма загрузки из SVN svn. Механизм загрузки использует переменные FETCHCOMMAND_svn, DL_DIR, SRCDATE. FETCHCOMMAND содержит команду для работы с subversion, DL_DIR указывает каталог для сохранения, SRCDATE указывает дату используемую для получения данных (специальное значение "now" используется для обновления при каждой сборке). Поддерживаются следующие параметры: proto, rev. proto указывает на используемый для обращения к хранилищу протокол, rev указывает на используемую ревизию. SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667" SRC_URI = "svn://svn.oe.handhelds.org/svn/;module=opie;proto=svn+ssh;date=20060126"

URN для механизма загрузки из GITgit. Используемые переменные DL_DIR, GITDIR. DL_DIR используется для указания каталога сохранения полученных данных. GITDIR используется в качестве базового каталога для клонирования git дерева. Поддерживаются следующие параметры tag, protocol. tag указывает на используемый тег git, по умолчанию это master. protocol указывает на используемый git протокол. По умолчанию это rsync. SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"

bitbake это основная команда в системе. Она позволяет исполнять как задачи в отдельном .bb файле, так и исполнение заданной задачи из множества .bb файлов с учетом зависимостей между ними.

$ bitbake --help использование: bitbake [параметры] [пакет ...] Исполняет указанную задача (по умолчанию 'build') для множества BitBake файлов. Ожидается что переменная BBFILES определена и содержит список разделенных проблами файлов, которые могут быть исполнены. BBFILES поддерживает маски. По умолчанию BBFILES это список .bb файлов в текущем каталоге. параметры: --version показывает весрию программы и завершается. -h, --help показывает это сообщение и завершается. -b BUILDFILE, --buildfile=BUILDFILE выполняет задачи указаном .bb файле, игнорируя пакет в BBFILES. -k, --continue продолжить после ошибки, если возможно. В случае если выполнение цели провалено, то все зависящие от нее не могут быть выполнены, остальные зависисти этих целей продолжат выполнятся. -f, --force принудительно перезапустить указаную задачу, игнорируя ее статус -i, --interactive перейти в интерактивный режим (BitBake shell). -c CMD, --cmd=CMD Указать задачу для запуска. Учтите что таким образом выполняется только указанная задача, зависимости игнорируются. К примеру если задача зависит от 'compile', то ее вызов не произойдет (используйте только когда вы знаете что делаете). В base.bbclass определена задача listtasks вызов которые отобразит доступные для выполнения задачи. -r FILE, --read=FILE считать этот файл до файла bitbake.conf -v, --verbose увеличение подробности вывода производимых действий -D, --debug Увеличить отладочный уровень. Может быть указан больше одного раза. -n, --dry-run не исполнять, только отобразить действия. -p, --parse-only выйти после завершения разбора файлов BB (только для разработчиков) -d, --disable-psyco отключить использование JIT компилятора psyco (не рекомендуется) -s, --show-versions показать текущую и предпочитаемую версию всех пакетов -e, --environment показать глобальное окружение или специфичное для пакета окружение (это используется при bbread) -g, --graphviz построить дерево зависимостей для указанных пакетов в dot синтаксисе graphiz -I IGNORED_DOT_DEPS, --ignore-deps=IGNORED_DOT_DEPS Игнорировать зависимости из списка при построении дерева зависимостей. Это позволит сделать дерево более простым. -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS Показать отладочную информацию для указанных доменов отладки -P, --profile профилирование исполняемой команды и вывод отчета Для выполнения задач в одном файле, необходимо указать его в запросе после чего bitbake разбирает его и выполняет указаную задачу (или build по умолчанию). При этом если необходимо, учитываются зависимости между задачами. Запуск задачи clean: $ bitbake -b blah_1.0.bb -c clean Запуск задачи build: $ bitbake -b blah_1.0.bb При использовании множества файлов .bb возникают некоторые сложности. Во-первых необходим механизм, который позволит сообщить bitbake, о том что файлы доступны и какой из них наобходим для выполнения. Во-вторых - механизм учета зависимостей для каждого.bb файла, как во время сборки, так и во время выполнения. В-третьих - механизм указания предпочтений пользователя среди множества .bb файлов предоставляющих одинаковый функционал или множества версий .bb. Далее в разделе Метаданные, вы узнаете каким образом их можно настраивать. Стоит отметить, что в случае множества файлов, команда bitbake без использования параметра --buildfile использует псевдоним, который не является именем файла или чем-то еще. По умолчанию, .bb предоставляет псевдонимы: имяпакета, имяпакета-версия, имяпакета-версия-ревизия. $ bitbake blah $ bitbake blah-1.0 $ bitbake blah-1.0-r0 $ bitbake -c clean blah $ bitbake virtual/whatever $ bitbake -c clean virtual/whatever BitBake позволяет строить граф зависимостей используя dot синтаксис. Эти граф можно конвертировать в графическое представление используя приложение dot из пакета graphviz. В результате построения зависимострей в текущей директории появятся два файла, depends.dot содержащий информацию о зависимостях на уровне пакетов и task-depends.dot содержащий зависимости на уровне задач. Для исключения из графа стандартных зависимостей вы можете добавить -I depend. Это позволяет создавать более короткие и понятные графы. К примеру таким образом можно убрать из DEPENDS унаследованные классы (к примеру base.bbclass). $ bitbake -g blah $ bitbake -g -I virtual/whatever -I bloom blah

Переменные влияющие на работу bitbake:

Переменная указывает какое количество потоков bitbake может запускать одновременно (по умолчанию: 1).

Как вы могли видеть из справки bitbake или из описания .bb файлов,переменная BBFILES указывает где bitbake ищет .bb файлы. Эта переменная содержит список файлов разделенных пробелами, или их масок (к примеру recipes/*/*.bb). BBFILES = "/path/to/bbfiles/*.bb" Что касается зависимостей, то ожидается что в .bb файле опеделена переменная DEPENDS, которая содержит список имен пакетов разделенных пробелами. Имена могут указываются в PN. По умолчанию в качестве PN используется часть имени .bb файла. a.bb: PN = "package-a" DEPENDS += "package-b" b.bb: PN = "package-b" Этот пример демонстрирует каким образом можно использовать переменную PROVIDES, для указания какую функциональность предоставляет .bb файл. package1.bb: PROVIDES += "virtual/package" package2.bb: DEPENDS += "virtual/package" package3.bb: PROVIDES += "virtual/package" Как вы видите два разных .bb файла предоставляют аналогичную функциональность (virtual/package). Из-за этого требуется указание пользователем, какой из этих файлов будет использоваться. Указать что будет использоваться package1 можно добавив в .conf файл следующую переменную со значением package1: PREFERRED_PROVIDER_virtual/package = "package1" Когда имеется множество версий одного и того же пакета, bitbake по умолчанию выбирает наиболее новую версию. Если в .bb значение переменной DEFAULT_PREFERENCE меньше чем в других .bb файлах (по умолчанию это 0), то он никогда не выбирается. Это позволяет разработчикам сопровождающим репозиторий .bb файлов указывать необходимую версию по умолчанию. Так же это позволяет изменять предпочтения локально не взирая на предпочтения в репозитории. К примеру если первый файл .bb имеет имя a_1.1.bb, то переменная PN будет иметь значение a, а переменная PV будет иметь значение 1.1. И если при этом имеется файл a_1.2.bb, то bitbake выберет 1.2 по умолчанию. Однако если определить в .conf файле, который обрабатыватся bitbake, ниже приведенную переменную, то будет выбрана версия 1.1 PREFERRED_VERSION_a = "1.1" Коллекции .bb файлов позволяют использовать множество репозиториев bb файлов содержащих одинаковые пакеты. К примеру это позволяет использовать отдельную копию основного репозитория со своими изменениями, невошедшими в основной репозиторий. Для этого в .conf прописываем: BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb" BBFILE_COLLECTIONS = "upstream local" BBFILE_PATTERN_upstream = "^/stuff/openembedded/" BBFILE_PATTERN_local = "^/stuff/openembedded.modified/" BBFILE_PRIORITY_upstream = "5" BBFILE_PRIORITY_local = "10"