Hob integration patches

PATCH In review Joshua Lock 6 participants 14 messages Jul 12, 2011 – Jul 19, 2011

Share & tools

Joshua Lock

author

2011-07-12 23:28 UTC #0 lore raw

cover Hob integration patches

Hob is the BitBake GUI I've been working on, the following pair of patches make it a little more nicely integrated into OE-Core.

The first adds a variable to image_types.bbclass that the GUI can use to determine what image types are available.

The second adds a wrapper script to call the GUI with a postfile, if the UI can find hob.local.conf any configuration settings made in the UI will be written to that file, rather than local.conf, ensuring that configuration changes made in the GUI don't affect CLI builds.

The following changes since commit a6e9edb7b4b5b0bdb067a59d691d33fba8948963:

sato-sdk: add clutter for sato-sdk image (2011-07-12 15:23:35 +0100)

are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib josh/hob
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/hob

Joshua Lock (2):
classes/image_types: add a variable to list available IMAGE_FSTYPE's scripts/hob: wrapper script to run hob gui with a UI specific config
file

 meta/classes/image_types.bbclass |    2 ++
 scripts/hob                      |   18 ++++++++++++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)
 create mode 100755 scripts/hob

Signature · 1 line

1.7.6

Joshua Lock

author

2011-07-12 23:28 UTC #1 lore raw

PATCH 1/2 classes/image_types: add a variable to list available IMAGE_FSTYPE's

This is for use in the Hob GUI to enable the user to change the type of the generated image.

Signed-off-by Joshua Lock <[email protected]>

---
 meta/classes/image_types.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

meta/classes/image_types.bbclass +2 -0

index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
 IMAGE_DEPENDS_ubi = "mtd-utils-native"
 IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"

Signature · 1 line

1.7.6

Tom Rini

2011-07-12 23:42 UTC #2 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 13 lines · Joshua Lock

This is for use in the Hob GUI to enable the user to change the type of the generated image.
Signed-off-by Joshua Lock <[email protected]>
---
 meta/classes/image_types.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +0 -0
index 89a745c..29d7a57 100644

meta/classes/image_types.bbclass IMAGE_DEPENDS_cpio.xz = "xz-native" · line 106

Quoted 5 lines

meta/classes/image_types.bbclass +2 -0

@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
 IMAGE_DEPENDS_ubi = "mtd-utils-native"
 IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"

Concept is fine, but please don't list ubi and ubifs just list ubi.

Signature · 2 lines

Tom Rini
Mentor Graphics Corporation

Gary Thomas

2011-07-13 00:41 UTC #3 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 17 lines · Tom Rini

Quoted 16 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the generated image.
Signed-off-by Joshua Lock<[email protected]>
---
  meta/classes/image_types.bbclass |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +0 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
  IMAGE_DEPENDS_ubi = "mtd-utils-native"
  IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 

Quoted 4 lines

meta/classes/image_types.bbclass IMAGE_DEPENDS_cpio.xz = "xz-native" · line 106
Quoted 2 lines
meta/classes/image_types.bbclass +2 -0
+# This variable is available to request which values are suitable for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.

Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?

Signature · 4 lines

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Tom Rini

2011-07-13 00:48 UTC #4 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 20 lines · Gary Thomas

Quoted 19 lines · Tom Rini
Quoted 18 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
  meta/classes/image_types.bbclass |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +0 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
  IMAGE_DEPENDS_ubi = "mtd-utils-native"
  IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
meta/classes/image_types.bbclass +1 -0
+# This variable is available to request which values are suitable
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?

Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.

Signature · 2 lines

Tom Rini
Mentor Graphics Corporation

Gary Thomas

2011-07-13 00:56 UTC #5 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 28 lines · Tom Rini

Quoted 27 lines · Gary Thomas
Quoted 25 lines · Tom Rini
Quoted 19 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
   meta/classes/image_types.bbclass |    2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +1 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
   IMAGE_DEPENDS_ubi = "mtd-utils-native"
   IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable
Quoted 3 lines
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.

Quoted 7 lines

Quoted 1 line
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?
Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.

I might be missing something, but I don't see why this rule is necessary
in image_types.bbclass:
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"

Having it there leads to the confusion (I was) that ubifs was useful.

At least for me, I can build ubi images with that rule removed.

Signature · 4 lines

------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Tom Rini

2011-07-13 01:15 UTC #6 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 38 lines · Gary Thomas

Quoted 28 lines · Tom Rini
Quoted 27 lines · Gary Thomas
Quoted 25 lines · Tom Rini
Quoted 19 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
   meta/classes/image_types.bbclass |    2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +1 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
   IMAGE_DEPENDS_ubi = "mtd-utils-native"
   IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable
Quoted 3 lines
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.
Quoted 8 lines
Quoted 2 lines
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?
Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.

Quoted 8 lines

I might be missing something, but I don't see why this rule is necessary in image_types.bbclass:
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
Having it there leads to the confusion (I was) that ubifs was useful.
At least for me, I can build ubi images with that rule removed.

OK, refreshed my memory again. We have ubifs (and it might indeed need some quick kicking/fixing) target (a) since that's what was there to start with, but not quite enough (b) for advanced users. There is a point to making a ubifs image which is when you're making a complex ubi volume (either outside of OE or in your collection/layer that provides a more complex ubinize conf).

The problem in oe-core today is that we were using non-standard extensions on the ubifs part to try and distinguish between usable standalone files (ubi) and parts (ubifs).

Signature · 2 lines

Tom Rini
Mentor Graphics Corporation

Richard Purdie

2011-07-13 11:28 UTC #7 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 55 lines · Tom Rini

Quoted 38 lines · Gary Thomas
Quoted 28 lines · Tom Rini
Quoted 27 lines · Gary Thomas
Quoted 25 lines · Tom Rini
Quoted 19 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
   meta/classes/image_types.bbclass |    2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +1 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
   IMAGE_DEPENDS_ubi = "mtd-utils-native"
   IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable
Quoted 3 lines
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.
Quoted 8 lines
Quoted 2 lines
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?
Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.
Quoted 8 lines
I might be missing something, but I don't see why this rule is necessary in image_types.bbclass:
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
Having it there leads to the confusion (I was) that ubifs was useful.
At least for me, I can build ubi images with that rule removed.
OK, refreshed my memory again. We have ubifs (and it might indeed need some quick kicking/fixing) target (a) since that's what was there to start with, but not quite enough (b) for advanced users. There is a point to making a ubifs image which is when you're making a complex ubi volume (either outside of OE or in your collection/layer that provides a more complex ubinize conf).

Quoted 3 lines

The problem in oe-core today is that we were using non-standard extensions on the ubifs part to try and distinguish between usable standalone files (ubi) and parts (ubifs).

Surely if you're doing this extra processing, you could just define the IMAGE_CMD_ubifs variable too?

I'm a little worried about having something there that is effectively unusable on its own...

Cheers,

Richard

Tom Rini

2011-07-13 14:14 UTC #8 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Quoted 60 lines · Richard Purdie

Quoted 55 lines · Tom Rini
Quoted 38 lines · Gary Thomas
Quoted 28 lines · Tom Rini
Quoted 27 lines · Gary Thomas
Quoted 25 lines · Tom Rini
Quoted 19 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
   meta/classes/image_types.bbclass |    2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +1 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
   IMAGE_DEPENDS_ubi = "mtd-utils-native"
   IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are suitable
Quoted 3 lines
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.
Quoted 8 lines
Quoted 2 lines
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?
Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.
Quoted 8 lines
I might be missing something, but I don't see why this rule is necessary in image_types.bbclass:
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
Having it there leads to the confusion (I was) that ubifs was useful.
At least for me, I can build ubi images with that rule removed.
OK, refreshed my memory again. We have ubifs (and it might indeed need some quick kicking/fixing) target (a) since that's what was there to start with, but not quite enough (b) for advanced users. There is a point to making a ubifs image which is when you're making a complex ubi volume (either outside of OE or in your collection/layer that provides a more complex ubinize conf).
Quoted 3 lines
The problem in oe-core today is that we were using non-standard extensions on the ubifs part to try and distinguish between usable standalone files (ubi) and parts (ubifs).

Quoted 5 lines

Surely if you're doing this extra processing, you could just define the IMAGE_CMD_ubifs variable too?
I'm a little worried about having something there that is effectively unusable on its own...

Well, ubifs is unusable without being in a ubi contanier. But a ubi
container can have anything in it, we just make a simple container to give people a starting point.

Signature · 2 lines

Tom Rini
Mentor Graphics Corporation

Koen Kooi

2011-07-13 19:59 UTC #9 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

Op 13 jul 2011, om 16:10 heeft Tom Rini het volgende geschreven:

Quoted 65 lines · Richard Purdie

Quoted 64 lines · Tom Rini
Quoted 56 lines · Gary Thomas
Quoted 39 lines · Tom Rini
Quoted 29 lines · Gary Thomas
Quoted 28 lines · Tom Rini
Quoted 26 lines · Joshua Lock
Quoted 19 lines
This is for use in the Hob GUI to enable the user to change the type of the
generated image.
Signed-off-by Joshua Lock<[email protected]>
---
  meta/classes/image_types.bbclass |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +1 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
  IMAGE_DEPENDS_ubi = "mtd-utils-native"
  IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 
+# This variable is available to request which values are  
Quoted 4 lines
suitable
for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.
Quoted 8 lines
Quoted 2 lines
Perhaps the [brokwn] rule to explicitly build ubifs should also be purged?
Nope, that's how the ubi is created. Essentially at the time anyhow, OE didn't make it too easy to add in an image that needs to be in a container to be used. So we have the ubifs rule (yes, that needs a cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create a simple ubi image.
Quoted 8 lines
I might be missing something, but I don't see why this rule is necessary in image_types.bbclass:
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
Having it there leads to the confusion (I was) that ubifs was useful.
At least for me, I can build ubi images with that rule removed.
OK, refreshed my memory again. We have ubifs (and it might indeed need some quick kicking/fixing) target (a) since that's what was there to start with, but not quite enough (b) for advanced users. There is a point to making a ubifs image which is when you're making a complex ubi volume (either outside of OE or in your collection/layer that provides a more complex ubinize conf).
Quoted 3 lines
The problem in oe-core today is that we were using non-standard extensions on the ubifs part to try and distinguish between usable standalone files (ubi) and parts (ubifs).
Surely if you're doing this extra processing, you could just define the IMAGE_CMD_ubifs variable too?

Quoted 6 lines

Quoted 2 lines
I'm a little worried about having something there that is effectively unusable on its own...
Well, ubifs is unusable without being in a ubi contanier. But a ubi
container can have anything in it, we just make a simple container to give people a starting point.

Being able to generate a eaw ubifs is usefull when you already have the container and only want to reflash, but don't want to trash the ubi erase cycle count.

Joshua Lock

author

2011-07-13 02:38 UTC #10 lore raw

Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

In reply to Tom Rini

Quoted 17 lines · Tom Rini

Quoted 16 lines · Joshua Lock
This is for use in the Hob GUI to enable the user to change the type of the generated image.
Signed-off-by Joshua Lock <[email protected]>
---
 meta/classes/image_types.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/image_types.bbclass +0 -0
index 89a745c..29d7a57 100644
@@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native"
 IMAGE_DEPENDS_ubi = "mtd-utils-native"
 IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 

Quoted 5 lines

meta/classes/image_types.bbclass IMAGE_DEPENDS_cpio.xz = "xz-native" · line 106
Quoted 2 lines
meta/classes/image_types.bbclass +2 -0
+# This variable is available to request which values are suitable for IMAGE_FSTYPES
+IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs squashfs-lzma ubi ubifs"
Concept is fine, but please don't list ubi and ubifs just list ubi.

Okey dokes, v2 coming up with only ubi listed. If it's as complex as skimming this thread seems we probably don't want ubifs in a GUI...

Thanks Tom,

Joshua

Signature · 3 lines

Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Joshua Lock

author

2011-07-12 23:28 UTC #11 lore raw

PATCH 2/2 scripts/hob: wrapper script to run hob gui with a UI specific config file

In reply to Joshua Lock

This ensures any configuration changes made in the GUI are only set when using hob.
The default hob.local.conf is generated with a line which adds image_types to INHERITS so that the GUI can introspect the available FSTYPES.

Signed-off-by Joshua Lock <[email protected]>

---
 scripts/hob |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100755 scripts/hob

scripts/hob new file +18 -0

new file mode 100755
index 0000000..19930ba
@@ -0,0 +1,18 @@
+#!/usr/bin/env bash
+if ! (test -r "$BUILDDIR/conf/hob.local.conf"); then
+    cat <<EOM
+You had no conf/hob.local.conf file. An initial version of this configuration
+file has therefore been created for you. This file will be used to store any
+configuration values you set in hob.
+
+EOM
+(cat <<EOF
+INHERIT += "image_types"
+EOF
+) > conf/hob.local.conf
+fi
+
+bitbake -R conf/hob.local.conf -t xmlrpc -u hob
+
+ret=$?
+exit $ret

Signature · 1 line

1.7.6

Saul Wold

2011-07-19 18:34 UTC #12 lore raw

In reply to Joshua Lock

Quoted 15 lines · Joshua Lock

Hob is the BitBake GUI I've been working on, the following pair of patches make it a little more nicely integrated into OE-Core.
The first adds a variable to image_types.bbclass that the GUI can use to determine what image types are available.
The second adds a wrapper script to call the GUI with a postfile, if the UI can find hob.local.conf any configuration settings made in the UI will be written to that file, rather than local.conf, ensuring that configuration changes made in the GUI don't affect CLI builds.
The following changes since commit a6e9edb7b4b5b0bdb067a59d691d33fba8948963:
   sato-sdk: add clutter for sato-sdk image (2011-07-12 15:23:35 +0100)

Quoted 9 lines

are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib josh/hob
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/hob
Joshua Lock (2):
classes/image_types: add a variable to list available IMAGE_FSTYPE's scripts/hob: wrapper script to run hob gui with a UI specific config
file

The scripts/hob patch has been merged, but the image_types is pending a v2 I believe.

Thanks
Sau!

Quoted 5 lines

  meta/classes/image_types.bbclass |    2 ++
  scripts/hob                      |   18 ++++++++++++++++++
  2 files changed, 20 insertions(+), 0 deletions(-)

create mode 100755 scripts/hob

Joshua Lock

author

2011-07-19 19:14 UTC #13 lore raw

Quoted 20 lines · Saul Wold

Quoted 19 lines · Joshua Lock
Hob is the BitBake GUI I've been working on, the following pair of patches make it a little more nicely integrated into OE-Core.
The first adds a variable to image_types.bbclass that the GUI can use to determine what image types are available.
The second adds a wrapper script to call the GUI with a postfile, if the UI can find hob.local.conf any configuration settings made in the UI will be written to that file, rather than local.conf, ensuring that configuration changes made in the GUI don't affect CLI builds.
The following changes since commit a6e9edb7b4b5b0bdb067a59d691d33fba8948963:
   sato-sdk: add clutter for sato-sdk image (2011-07-12 15:23:35 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib josh/hob
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/hob

Quoted 7 lines

Quoted 5 lines
Joshua Lock (2):
classes/image_types: add a variable to list available IMAGE_FSTYPE's scripts/hob: wrapper script to run hob gui with a UI specific config
file
The scripts/hob patch has been merged, but the image_types is pending a v2 I believe.

The v2 was already merged:
http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=12600138721262ce02e9dd243bcf44e52e065179

Thanks,
Joshua

Signature · 3 lines

Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre