{"id":7035,"date":"2025-11-11T08:21:22","date_gmt":"2025-11-11T07:21:22","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=7035"},"modified":"2025-11-11T13:11:35","modified_gmt":"2025-11-11T12:11:35","slug":"se-passer-de-poky","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2025\/11\/11\/se-passer-de-poky\/","title":{"rendered":"Se passer de Poky"},"content":{"rendered":"
\n
\"\"<\/a><\/figure><\/div>\n\n\n

L’\u00e9co-syst\u00e8me \u00ab\u00a0The Yocto Project<\/em>\u00a0\u00bb est assez touffu. En effet, Yocto Project chapeaute plusieurs sous-projets pour lesquels il fournit des ressources de d\u00e9veloppement : Bitbake, Open Embedded, Poky, les layers<\/em> des sponsors \u00ab\u00a0platiniums<\/em>\u00a0\u00bb ainsi que l’h\u00e9bergement de nombreux layers<\/em> supportant diverses plateformes mat\u00e9rielles.<\/p>\n\n\n\n

Depuis plus d’une d\u00e9cennie, la mise en route d’un projet Yocto passait par l’utilisation d’un starter pack<\/em> contenant les outils de base et les recettes minimales pour produire une image. Cet environnement se nommait Poky<\/strong>.<\/p>\n\n\n\n\n\n\n\n

Poky \u00e9tait bien pratique pour s’assurer d’une mise en \u0153uvre initiale correcte, et toutes mes sessions de formation et tutoriels sur Yocto commen\u00e7aient syst\u00e9matique par un :<\/p>\n\n\n\n

git  clone  git:\/\/git.yoctoproject.org\/poky  -b  <current-branch><\/code><\/pre>\n\n\n\n
Toutefois les mainteneurs de Yocto Project ont pris la d\u00e9cision de ne plus maintenir<\/strong> Poky \u00e0 partir de la future branche Wrynose<\/em> d’Avril prochain. Leur objectif : favoriser l’utilisation d’un outil nomm\u00e9 bitbake-setup<\/code> qui peut s’occuper de la mise en \u0153uvre de l’environnement de travail.<\/p>\n\n\n\n
\u00c0 titre personnel cela ne m’enchante gu\u00e8re car bitbake-setup<\/code> est un concurrent de l’outil Yocto Cooker<\/strong> auquel j’ai contribu\u00e9 et que j’ai pr\u00e9sent\u00e9 dans plusieurs articles ici<\/a>.  De plus Yocto Cooker dispose de fonctionnalit\u00e9s suppl\u00e9mentaires que j’estime importantes.<\/p>\n\n\n\n
En attendant que Yocto Cooker soit pr\u00eat \u00e0 se passer de Poky (ce qui ne saurait tarder). Je vous pr\u00e9sente ici la m\u00e9thode manuelle que j’emploie pour construire l’environnement de travail et faire un build<\/em> simple sans utiliser Poky.<\/p>\n\n\n\n
Commen\u00e7ons par nous cr\u00e9er un r\u00e9pertoire pour accueillir les layers<\/em> et un autre pour les futurs builds<\/em>.<\/p>\n\n\n\n
[no-poky]$ mkdir layers<\/strong>\n[no-poky]$ mkdir builds<\/strong><\/code><\/pre>\n\n\n\n
T\u00e9l\u00e9chargeons, dans le sous-dossier layers<\/code> deux d\u00e9p\u00f4ts git<\/code> : celui de bitbake<\/code> (l’outil de construction utilis\u00e9 dans le projet Yocto) et celui de openembedded-core<\/code> (le layer<\/em> contenant les recettes de base pour construire une image) :<\/p>\n\n\n\n
[no-poky]$ cd  layers\/<\/strong>\n[layers]$ git  clone  git:\/\/git.openembedded.org\/bitbake<\/strong>\n[layers]$ cd bitbake<\/strong>\n[bitbake]$ git  checkout  yocto-5.0.13<\/strong>\n[bitbake]$ cd  ..<\/strong>\n[layers]$ git  clone  git:\/\/git.openembedded.org\/openembedded-core  -b scarthgap<\/strong>\n[layers]$ cd ..<\/strong>\n[no-poky]$ \n<\/code><\/pre>\n\n\n\n
Il est important que ces deux r\u00e9pertoires soient c\u00f4te-\u00e0-c\u00f4te dans l’arborescence, le script oe-init-build-env<\/code> que nous allons appeler se trouve dans openembedded-code<\/code> et recherche bitbake<\/code> dans le r\u00e9pertoire se trouvant \u00e0 c\u00f4t\u00e9 de lui.<\/p>\n\n\n\n
\u00ab\u00a0Sour\u00e7ons\u00a0\u00bb le script pour qu’il puisse cr\u00e9er notre dossier de build<\/em>, et qu’il configure les variables d’environnement du shell n\u00e9cessaires.<\/p>\n\n\n\n
[no-poky]$ source  layers\/openembedded-core\/oe-init-build-env  builds\/build-qemu<\/strong>\n   [...]\n[build-qemu]$ <\/code><\/pre>\n\n\n\n
J’aime bien \u00e9diter le fichier  conf\/local.conf<\/code>, pour d\u00e9-commenter et compl\u00e9ter les deux lignes suivantes afin que les dossiers downloads<\/code> et sstate-cache<\/code> soient partag\u00e9s entre mes diff\u00e9rents builds<\/em>. Ce n’est pas indispensable, mais c’est une bonne pratique.<\/p>\n\n\n\n
DL_DIR ?= \"${TOPDIR}\/..\/..\/<\/strong>downloads\"\n  [...]\nSSTATE_DIR ?= \"${TOPDIR}\/..\/..\/<\/strong>sstate-cache\"\n<\/code><\/pre>\n\n\n\n
Enfin, nous pouvons lancer un build minimal. Par d\u00e9faut il s’agira d’une \u00e9mulation de machine x86_64 par Qemu :<\/p>\n\n\n\n
[build-qemu]$ bitbake core-image-minimal<\/strong><\/code><\/pre>\n\n\n\n
Patientons quelques dizaines de minutes et testons le r\u00e9sultat :<\/p>\n\n\n\n
[build-qemu]$ runqemu  nographic<\/strong>\n  [...]\n\nOpenEmbedded nodistro.0 qemux86-64 \/dev\/ttyS0\n\nqemux86-64 login: root<\/strong>\nroot@qemux86-64:~# uname -a<\/strong>\nLinux qemux86-64 6.6.111-yocto-standard #1 SMP PREEMPT_DYNAMIC Tue Oct 14 01:25:53 UTC 2025 x86_64 GNU\/Linux\nroot@qemux86-64:~# \n<\/code><\/pre>\n\n\n\n
Raspberry Pi<\/h2>\n\n\n\n
Si l’on souhaite faire une image pour une vraie carte et non plus une \u00e9mulation, il va falloir charger les recettes qui la concernent. Elle sont regroup\u00e9s dans diff\u00e9rents layers, dont bon nombre sont h\u00e9berg\u00e9s sur les serveurs de Yocto Project. Prenons par exemple un Raspberry Pi 4 :<\/p>\n\n\n\n
[no-poky]$ cd  layers<\/strong>\n[layers]$ git  clone  git:\/\/git.yoctoproject.org\/meta-raspberrypi  -b scarthgap<\/strong>\n[layers]$ cd  ..<\/strong>\n[no-poky]$ source  .\/layers\/openembedded-core\/oe-init-build-env  builds\/build-rpi4<\/strong>\n[build-rpi4]$<\/code><\/pre>\n\n\n\n
Avant de lancer la compilation, il faut penser \u00e0 ajouter le layer meta-raspberrypi<\/code> \u00e0 la liste des layers pris en compte :<\/p>\n\n\n\n
[build-rpi4]$ bitbake-layers  add-layer  ..\/..\/layers\/meta-raspberrypi\/<\/strong>\n<\/code><\/pre>\n\n\n\n
Puis nous configurons le fichier local.conf<\/code> en ajoutant les lignes suivantes  :<\/p>\n\n\n\n
MACHINE = \"raspberrypi4-64\"\nENABLE_UART = \"1\"\nLICENSE_FLAGS_ACCEPTED += \"synaptics-killswitch\"\nDL_DIR ?= \"${TOPDIR}\/..\/..\/downloads\"\nSSTATE_DIR ?= \"${TOPDIR}\/..\/..\/sstate-cache\"<\/code><\/pre>\n\n\n\n
Enfin, nous lan\u00e7ons un build<\/em> un petit peu plus complet que le pr\u00e9c\u00e9dent : <\/p>\n\n\n\n
[build-rpi4]$ bitbake core-image-base<\/strong><\/code><\/pre>\n\n\n\n
Une fois l’image produite et disponible dans tmp-glibc\/deploy\/images\/raspberrypi4-64\/<\/code> sous le nom core-image-base-raspberrypi4-64.rootfs.wic.bz2<\/code> on pourra utiliser un outil comme bmaptool<\/code> pour la flasher<\/em> sur une carte SD.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
Pass\u00e9 le premier moment de surprise face \u00e0 la disparition de l’outil de d\u00e9marrage d’un projet avec Yocto que repr\u00e9sentait Poky, nous pouvons constater que la situation n’est pas beaucoup plus complexe, il nous suffit globalement de t\u00e9l\u00e9charger les repositories<\/em> de Bitbake<\/strong> et d’Open-Embedded Core<\/strong>, que l’on agr\u00e9mentera \u00e9ventuellement du layer meta-yocto<\/strong><\/code> (sur le serveur de Yocto Project<\/a>) pour retrouver la situation pr\u00e9c\u00e9dente.<\/p>\n\n\n\n
Je mettrai \u00e0 jour mes supports de formation dans les semaines \u00e0 venir et modifierai mon cours en ligne<\/strong> sur Yocto Project<\/a> lorsque la disparition de Poky aura \u00e9t\u00e9 finalis\u00e9e. Nous allons \u00e9galement mettre \u00e0 jour Yocto Cooker<\/strong><\/a> prochainement.

Et si vous cherchez un syst\u00e8me plus simple pour produire un environnement Linux embarqu\u00e9, n’oubliez pas la solution Buildroot<\/strong><\/a>.<\/p>\n\n\n\n
<\/p>","protected":false},"excerpt":{"rendered":"
L’éco-système « The Yocto Project » est assez touffu. En effet, Yocto Project chapeaute plusieurs sous-projets pour lesquels il fournit des ressources de développement : Bitbake, Open Embedded, Poky, les layers des sponsors « platiniums » ainsi que l’hébergement de nombreux layers supportant diverses plateformes matérielles. Depuis plus d’une décennie, la mise en route d’un projet Yocto passait par l’utilisation […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-7035","post","type-post","status-publish","format-standard","hentry","category-linux-2"],"_links":{"self":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/7035","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/comments?post=7035"}],"version-history":[{"count":16,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/7035\/revisions"}],"predecessor-version":[{"id":7063,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/posts\/7035\/revisions\/7063"}],"wp:attachment":[{"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/media?parent=7035"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/categories?post=7035"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blaess.fr\/christophe\/wp-json\/wp\/v2\/tags?post=7035"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}