Skip to contentSkip to conversation

image.bbclass: Separate out image generation into a new task, do_image

PATCH In review Richard Purdie 2 participants 3 messages Jan 6, 2016 – Jan 17, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/4 image.bbclass: Separate out image generation into a new task, do_image

I've heard complaints from people trying to create more interesting image types about how hard it is to understand the rootfs/image generation code and that its a pain to develop/test/debug.

Having looked at it myself, the internal construction of shell functions which then gets passed into a multiprocessing pool is rather convoluted and it places rather odd constraints on when variables are expanded. Its therefore no wonder people find it confusing/complex.

This patch starts the process of splitting this up by separating out image generation from the do_rootfs task into a new do_image task.

meta/classes/image.bbclass +10 -4
index 81971fe..77a8548 100644
@@ -207,7 +207,6 @@ PACKAGE_EXCLUDE[type] = "list"
 
 fakeroot python do_rootfs () {
     from oe.rootfs import create_rootfs
-    from oe.image import create_image
     from oe.manifest import create_manifest
 
     # Handle package exclusions
@@ -244,9 +243,6 @@ fakeroot python do_rootfs () {
 
     # Generate rootfs
     create_rootfs(d)
-
-    # generate final images
-    create_image(d)
 }
 do_rootfs[dirs] = "${TOPDIR}"
 do_rootfs[lockfiles] += "${IMAGE_ROOTFS}.lock"
@@ -254,6 +250,16 @@ do_rootfs[cleandirs] += "${S}"
 do_rootfs[umask] = "022"
 addtask rootfs before do_build
 
+fakeroot python do_image () {
+    from oe.image import create_image
+
+    # generate final images
+    create_image(d)
+}
+do_image[dirs] = "${TOPDIR}"
+do_image[umask] = "022"
+addtask do_image after do_rootfs before do_build
+
 MULTILIBRE_ALLOW_REP =. "${base_bindir}|${base_sbindir}|${bindir}|${sbindir}|${libexecdir}|${sysconfdir}|${nonarch_base_libdir}/udev|/lib/modules/[^/]*/modules.*|"
 MULTILIB_CHECK_FILE = "${WORKDIR}/multilib_check.py"
 MULTILIB_TEMP_ROOTFS = "${WORKDIR}/multilib"
#1 lore raw

Hi Richard,

I have issues building a core-image-minimal Raspberry Pi 2 SD image after this series of patches using openembedded-core master (b3b679d5be86f73d1a06c7230cb00872f0a407b5) and meta-raspberrypi master (0d8e9271855ccb9bc21bdc0743f8e0f6ff0d2d5c).

| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_rpi-sdimg
| /home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.do_image_rpi-sdimg.8349: line 108: do_image_rpi-sdimg: command not found
| WARNING: /home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.do_image_rpi-sdimg.8349:1 exit 127 from
|   do_image_rpi-sdimg
| ERROR: Function failed: do_image_rpi-sdimg (log file is located at /home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_rpi-sdimg.8349)

openembedded-core 38237b7ac53c416f85c4a70a61acafc3404c8b5f - ok openembedded-core b3b679d5be86f73d1a06c7230cb00872f0a407b5 - fails

Any ideas?

Regards,
Jonathan

Quoted 55 lines · Richard Purdie

I've heard complaints from people trying to create more interesting image types about how hard it is to understand the rootfs/image generation code and that its a pain to develop/test/debug.

Having looked at it myself, the internal construction of shell functions which then gets passed into a multiprocessing pool is rather convoluted and it places rather odd constraints on when variables are expanded. Its therefore no wonder people find it confusing/complex.

This patch starts the process of splitting this up by separating out image generation from the do_rootfs task into a new do_image task.

meta/classes/image.bbclass +10 -4
index 81971fe..77a8548 100644
@@ -207,7 +207,6 @@ PACKAGE_EXCLUDE[type] = "list"
 
  fakeroot python do_rootfs () {
      from oe.rootfs import create_rootfs
-    from oe.image import create_image
      from oe.manifest import create_manifest
 
      # Handle package exclusions
@@ -244,9 +243,6 @@ fakeroot python do_rootfs () {
 
      # Generate rootfs
      create_rootfs(d)
-
-    # generate final images
-    create_image(d)
  }
  do_rootfs[dirs] = "${TOPDIR}"
  do_rootfs[lockfiles] += "${IMAGE_ROOTFS}.lock"
@@ -254,6 +250,16 @@ do_rootfs[cleandirs] += "${S}"
  do_rootfs[umask] = "022"
  addtask rootfs before do_build
 
+fakeroot python do_image () {
+    from oe.image import create_image
+
+    # generate final images
+    create_image(d)
+}
+do_image[dirs] = "${TOPDIR}"
+do_image[umask] = "022"
+addtask do_image after do_rootfs before do_build
+
  MULTILIBRE_ALLOW_REP =. "${base_bindir}|${base_sbindir}|${bindir}|${sbindir}|${libexecdir}|${sysconfdir}|${nonarch_base_libdir}/udev|/lib/modules/[^/]*/modules.*|"
  MULTILIB_CHECK_FILE = "${WORKDIR}/multilib_check.py"
  MULTILIB_TEMP_ROOTFS = "${WORKDIR}/multilib"
#2 lore raw
Quoted 19 lines · Jonathan Liu

I have issues building a core-image-minimal Raspberry Pi 2 SD image after this series of patches using openembedded-core master (b3b679d5be86f73d1a06c7230cb00872f0a407b5) and meta-raspberrypi master
(0d8e9271855ccb9bc21bdc0743f8e0f6ff0d2d5c).

Quoted 4 lines

DEBUG: Executing python function set_image_size
DEBUG: Python function set_image_size finished
DEBUG: Executing shell function do_image_rpi-sdimg

/home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux -gnueabi/core-image-minimal/1.0-r0/temp/run.do_image_rpi-sdimg.8349:
line 108: do_image_rpi-sdimg: command not found

Quoted 1 line

WARNING:

/home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux -gnueabi/core-image-minimal/1.0-r0/temp/run.do_image_rpi-sdimg.8349:1 exit 127 from

Quoted 2 lines

do_image_rpi-sdimg
ERROR: Function failed: do_image_rpi-sdimg (log file is located at

Quoted 7 lines

/home/build/git/pi2/build/tmp/work/raspberrypi2-custom-linux -gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_rpi-sdimg.8349)

openembedded-core 38237b7ac53c416f85c4a70a61acafc3404c8b5f - ok openembedded-core b3b679d5be86f73d1a06c7230cb00872f0a407b5 - fails

Any ideas?

Try the patch I just sent to the OE-Core list, "Handle image types containing '-' correctly". Looks like image types containing the "-" character would cause problems but I think there is a workaround.

Cheers,

Richard