Removing Hob for 2.1

Removing Hob for 2.1

[Paul Eggleton]

Hi folks,

So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) UI 
for some time now; Hob has basically been on life support for the past few 
releases. As of late last month in master, Toaster has the capability to 
select the packages in an image, removing the last thing that Hob could do 
that Toaster couldn't. This means it's about time we looked at removing Hob - 
particularly if we want to do so for the upcoming 2.1 release as we should 
really do so within the M3 development timeframe which is almost over.

To recap, the reasons why Hob ought to be removed include:

- The code is tightly woven into BitBake, making it fragile. This means it 
needs significant QA and maintenance on an ongoing basis.

- Some of the implementation is not ideal; we'll be able to remove some cruft 
from BitBake and OE-Core at the same time.

- It's GTK+ 2 based, not the current GTK+ 3.

- Toaster is now a much more capable UI and is being actively maintained

I'm maintaining a list of things we would drop together with Hob, so I could 
probably come up with a patchset - I just wanted to give people a heads up and 
double check that this is something we indeed want to do in 2.1. Any comments?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Removing Hob for 2.1

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Go ahead
On Feb 25, 2016 6:50 PM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
wrote:

> Hi folks,
>
> So we've been gearing up the Toaster web UI to replace the Hob (GTK+
> based) UI
> for some time now; Hob has basically been on life support for the past few
> releases. As of late last month in master, Toaster has the capability to
> select the packages in an image, removing the last thing that Hob could do
> that Toaster couldn't. This means it's about time we looked at removing
> Hob -
> particularly if we want to do so for the upcoming 2.1 release as we should
> really do so within the M3 development timeframe which is almost over.
>
> To recap, the reasons why Hob ought to be removed include:
>
> - The code is tightly woven into BitBake, making it fragile. This means it
> needs significant QA and maintenance on an ongoing basis.
>
> - Some of the implementation is not ideal; we'll be able to remove some
> cruft
> from BitBake and OE-Core at the same time.
>
> - It's GTK+ 2 based, not the current GTK+ 3.
>
> - Toaster is now a much more capable UI and is being actively maintained
>
> I'm maintaining a list of things we would drop together with Hob, so I
> could
> probably come up with a patchset - I just wanted to give people a heads up
> and
> double check that this is something we indeed want to do in 2.1. Any
> comments?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>

[-- Attachment #2: Type: text/html, Size: 2230 bytes --]

Re: [Openembedded-architecture] Removing Hob for 2.1

[Anders Darander]

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]

On Fri, 26 Feb 2016, 03:54 Khem Raj <raj.khem@gmail.com> wrote:

> Go ahead
>
Yes, go ahead.

>

[-- Attachment #2: Type: text/html, Size: 522 bytes --]

Re: [Openembedded-architecture] Removing Hob for 2.1

[Philip Balister]

On 02/25/2016 09:49 PM, Paul Eggleton wrote:
> Hi folks,
> 
> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) UI 
> for some time now; Hob has basically been on life support for the past few 
> releases. As of late last month in master, Toaster has the capability to 

Please remove Hob.

I've heard that the Linux Foundation training still mentions Hob, I'll
double check that this content is removed and shifted to Toaster.

Philip

> select the packages in an image, removing the last thing that Hob could do 
> that Toaster couldn't. This means it's about time we looked at removing Hob - 
> particularly if we want to do so for the upcoming 2.1 release as we should 
> really do so within the M3 development timeframe which is almost over.
> 
> To recap, the reasons why Hob ought to be removed include:
> 
> - The code is tightly woven into BitBake, making it fragile. This means it 
> needs significant QA and maintenance on an ongoing basis.
> 
> - Some of the implementation is not ideal; we'll be able to remove some cruft 
> from BitBake and OE-Core at the same time.
> 
> - It's GTK+ 2 based, not the current GTK+ 3.
> 
> - Toaster is now a much more capable UI and is being actively maintained
> 
> I'm maintaining a list of things we would drop together with Hob, so I could 
> probably come up with a patchset - I just wanted to give people a heads up and 
> double check that this is something we indeed want to do in 2.1. Any comments?
> 
> Cheers,
> Paul
> 

Re: [Openembedded-architecture] Removing Hob for 2.1

[nick]

On 2016-02-26 08:37 AM, Philip Balister wrote:
> On 02/25/2016 09:49 PM, Paul Eggleton wrote:
>> Hi folks,
>>
>> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) UI 
>> for some time now; Hob has basically been on life support for the past few 
>> releases. As of late last month in master, Toaster has the capability to 
> 
> Please remove Hob.
> 
> I've heard that the Linux Foundation training still mentions Hob, I'll
> double check that this content is removed and shifted to Toaster.
> 
> Philip
> 
>> select the packages in an image, removing the last thing that Hob could do 
>> that Toaster couldn't. This means it's about time we looked at removing Hob - 
>> particularly if we want to do so for the upcoming 2.1 release as we should 
>> really do so within the M3 development timeframe which is almost over.
>>
>> To recap, the reasons why Hob ought to be removed include:
>>
>> - The code is tightly woven into BitBake, making it fragile. This means it 
>> needs significant QA and maintenance on an ongoing basis.
>>
>> - Some of the implementation is not ideal; we'll be able to remove some cruft 
>> from BitBake and OE-Core at the same time.
>>
>> - It's GTK+ 2 based, not the current GTK+ 3.
>>
>> - Toaster is now a much more capable UI and is being actively maintained
>>
>> I'm maintaining a list of things we would drop together with Hob, so I could 
>> probably come up with a patchset - I just wanted to give people a heads up and 
>> double check that this is something we indeed want to do in 2.1. Any comments?
>>
I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless
we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier
distribution build tuning how big is the learning curve(I assume it isn't much). Further more
can Toaster be configured to make iso/vmware images as I find this very useful plus from what
I known Toaster needs to be run with a browser can it be made to run as a non browser based
service similar to Hob if not already done so.
Just my thoughts,
Nick
>> Cheers,
>> Paul
>>

Re: [Openembedded-architecture] Removing Hob for 2.1

[Paul Eggleton]

On Fri, 26 Feb 2016 09:26:43 nick wrote:
> I haven't been using the last few versions of Yocto, last I used was 1.8 I
> believe unless we just jumped to 2.0/2.1. I was wondering for people
> somewhat used to using HOB for easier distribution build tuning how big is
> the learning curve(I assume it isn't much). 

Shouldn't be a big deal. If anything it's been much more carefully designed 
with new users in mind.

> Further more can Toaster be configured to make iso/vmware images as I find
> this very useful 

Certainly, any image type you can produce from Hob you can produce from 
Toaster.

> plus from what I known Toaster needs to be run with a browser can it be made
> to run as a non browser based service similar to Hob if not already done so.

Toaster is entirely web-based so that isn't possible I'm afraid. It doesn't 
require a separate web server though if that's what you're concerned about - 
the default configuration is to run on a single machine and not listen 
externally.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Removing Hob for 2.1

[nick]

On 2016-02-26 08:37 AM, Philip Balister wrote:
> On 02/25/2016 09:49 PM, Paul Eggleton wrote:
>> Hi folks,
>>
>> So we've been gearing up the Toaster web UI to replace the Hob (GTK+ based) UI 
>> for some time now; Hob has basically been on life support for the past few 
>> releases. As of late last month in master, Toaster has the capability to 
> 
> Please remove Hob.
> 
> I've heard that the Linux Foundation training still mentions Hob, I'll
> double check that this content is removed and shifted to Toaster.
> 
> Philip
> 
>> select the packages in an image, removing the last thing that Hob could do 
>> that Toaster couldn't. This means it's about time we looked at removing Hob - 
>> particularly if we want to do so for the upcoming 2.1 release as we should 
>> really do so within the M3 development timeframe which is almost over.
>>
>> To recap, the reasons why Hob ought to be removed include:
>>
>> - The code is tightly woven into BitBake, making it fragile. This means it 
>> needs significant QA and maintenance on an ongoing basis.
>>
>> - Some of the implementation is not ideal; we'll be able to remove some cruft 
>> from BitBake and OE-Core at the same time.
>>
>> - It's GTK+ 2 based, not the current GTK+ 3.
>>
>> - Toaster is now a much more capable UI and is being actively maintained
>>
>> I'm maintaining a list of things we would drop together with Hob, so I could 
>> probably come up with a patchset - I just wanted to give people a heads up and 
>> double check that this is something we indeed want to do in 2.1. Any comments?
>>
I haven't been using the last few versions of Yocto, last I used was 1.8 I believe unless
we just jumped to 2.0/2.1. I was wondering for people somewhat used to using HOB for easier
distribution build tuning how big is the learning curve(I assume it isn't much). Further more
can Toaster be configured to make iso/vmware images as I find this very useful plus from what
I known Toaster needs to be run with a browser can it be made to run as a non browser based
service similar to Hob if not already done so.
Just my thoughts,
Nick
P.S. Sorry if anybody gets a second email as I was not subscribed to openembedded architecture.
>> Cheers,
>> Paul
>>

Re: [Openembedded-architecture] Removing Hob for 2.1

[Barros Pena, Belen]

On 26/02/2016 15:29,
"openembedded-architecture-bounces@lists.openembedded.org on behalf of
nick" <openembedded-architecture-bounces@lists.openembedded.org on behalf
of xerofoify@gmail.com> wrote:

>I was wondering for people somewhat used to using HOB for easier
>distribution build tuning how big is the learning curve

Well, this is a question only those people can answer :) and I would be
very interested in hearing what they have to say.

So, if you consider yourself one those people "somewhat used to using
HOB", and would like to try Toaster and give us some feedback, please
contact me off list.

Cheers,

Belén

Standalone image writer

[Paul Eggleton]

(changing subject line so people don't miss this slight tangent)

I'd almost completely forgotten, but the part of what we wrote for Hob to 
write images to a USB stick or SD card (bitbake/bin/image-writer) is actually 
a standalone application. There's not a lot to it - pick your image file and 
then the device you want to write it to; it has some logic in it to not let 
you accidentally write to devices that aren't USB sticks.

A few points:

- I'm not sure very many people know this tool exists, so it's likely it's not 
being widely used. Having said that it is a nice simple UI that does the job.

- It shares some code with Hob, but mostly not the bits with code quality 
issues, though it is still GTK+ 2 based.

- It doesn't support the advanced SD card writing functionality that has been 
implented within wic over the last few releases, which is pretty important for 
devices where a special partition layout is expected by the bootloader.

- Toaster can't really have this functionality in it because it's web based 
and the web server might not be running locally, so writing to a local USB 
stick or SD card isn't going to be practical from there; about all it could do 
is provide instructions on how to write the image once you've downloaded it.

- I believe there are other equivalent tools out there that various distros 
use for taking a downloadable ISO image and writing it to a USB stick. I 
haven't done a survey to find out if if any of them work in quite the same way; 
I know some of them actually unpack the image and then re-create a filesystem 
on the device, which isn't the right thing for our images.

- We do have a command-line equivalent in the form of scripts/contrib/ddimage 
in OE-Core. Of course it's command-line and thus less friendly but it does the 
job (and also has some safeguards against writing to the wrong device).

So what do we do with this? We have two choices really:

 A) Drop bitbake/bin/imagewriter along with Hob; we could potentially 
resurrect it again later if desired

 B) Preserve it along with the shared modules that it requires

Thoughts?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Standalone image writer

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]


> On Feb 28, 2016, at 4:17 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> (changing subject line so people don't miss this slight tangent)
> 
> I'd almost completely forgotten, but the part of what we wrote for Hob to
> write images to a USB stick or SD card (bitbake/bin/image-writer) is actually
> a standalone application. There's not a lot to it - pick your image file and
> then the device you want to write it to; it has some logic in it to not let
> you accidentally write to devices that aren't USB sticks.
> 
> A few points:
> 
> - I'm not sure very many people know this tool exists, so it's likely it's not
> being widely used. Having said that it is a nice simple UI that does the job.
> 
> - It shares some code with Hob, but mostly not the bits with code quality
> issues, though it is still GTK+ 2 based.
> 
> - It doesn't support the advanced SD card writing functionality that has been
> implented within wic over the last few releases, which is pretty important for
> devices where a special partition layout is expected by the bootloader.
> 
> - Toaster can't really have this functionality in it because it's web based
> and the web server might not be running locally, so writing to a local USB
> stick or SD card isn't going to be practical from there; about all it could do
> is provide instructions on how to write the image once you've downloaded it.
> 
> - I believe there are other equivalent tools out there that various distros
> use for taking a downloadable ISO image and writing it to a USB stick. I
> haven't done a survey to find out if if any of them work in quite the same way;
> I know some of them actually unpack the image and then re-create a filesystem
> on the device, which isn't the right thing for our images.
> 
> - We do have a command-line equivalent in the form of scripts/contrib/ddimage
> in OE-Core. Of course it's command-line and thus less friendly but it does the
> job (and also has some safeguards against writing to the wrong device).
> 
> So what do we do with this? We have two choices really:
> 
> A) Drop bitbake/bin/imagewriter along with Hob; we could potentially
> resurrect it again later if desired
> 
> B) Preserve it along with the shared modules that it requires
> 
> Thoughts?


Option A. There are USB writer tool in your favorite distros and OSes, and I have
seen people use those tools more often.

> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [Openembedded-architecture] Standalone image writer

[Trevor Woerner]

On 02/28/16 20:46, Khem Raj wrote:
>> On Feb 28, 2016, at 4:17 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>>
>> (changing subject line so people don't miss this slight tangent)
>>
>> I'd almost completely forgotten, but the part of what we wrote for Hob to
>> write images to a USB stick or SD card (bitbake/bin/image-writer) is actually
>> a standalone application. There's not a lot to it - pick your image file and
>> then the device you want to write it to; it has some logic in it to not let
>> you accidentally write to devices that aren't USB sticks.
>>
>> A few points:
>>
>> - I'm not sure very many people know this tool exists, so it's likely it's not
>> being widely used. Having said that it is a nice simple UI that does the job.
>>
>> - It shares some code with Hob, but mostly not the bits with code quality
>> issues, though it is still GTK+ 2 based.
>>
>> - It doesn't support the advanced SD card writing functionality that has been
>> implented within wic over the last few releases, which is pretty important for
>> devices where a special partition layout is expected by the bootloader.
>>
>> - Toaster can't really have this functionality in it because it's web based
>> and the web server might not be running locally, so writing to a local USB
>> stick or SD card isn't going to be practical from there; about all it could do
>> is provide instructions on how to write the image once you've downloaded it.
>>
>> - I believe there are other equivalent tools out there that various distros
>> use for taking a downloadable ISO image and writing it to a USB stick. I
>> haven't done a survey to find out if if any of them work in quite the same way;
>> I know some of them actually unpack the image and then re-create a filesystem
>> on the device, which isn't the right thing for our images.
>>
>> - We do have a command-line equivalent in the form of scripts/contrib/ddimage
>> in OE-Core. Of course it's command-line and thus less friendly but it does the
>> job (and also has some safeguards against writing to the wrong device).
>>
>> So what do we do with this? We have two choices really:
>>
>> A) Drop bitbake/bin/imagewriter along with Hob; we could potentially
>> resurrect it again later if desired
>>
>> B) Preserve it along with the shared modules that it requires
>>
>> Thoughts?
>
> Option A. There are USB writer tool in your favorite distros and OSes, and I have
> seen people use those tools more often.

Some platforms, e.g. Minnow, use their own image writing script (i.e. 
mkefidisk.sh). If there are other platforms which need some special tool 
that isn't generically available from the host and the hob tool could be 
made to accommodate them all, I'd prefer to see one tool that can do all 
of them instead of a bunch of tools, one for each platform.

Re: [Openembedded-architecture] Standalone image writer

[Gary Thomas]

On 02/29/2016 04:31 AM, Trevor Woerner wrote:
>
>
> On 02/28/16 20:46, Khem Raj wrote:
>>> On Feb 28, 2016, at 4:17 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>>>
>>> (changing subject line so people don't miss this slight tangent)
>>>
>>> I'd almost completely forgotten, but the part of what we wrote for Hob to
>>> write images to a USB stick or SD card (bitbake/bin/image-writer) is actually
>>> a standalone application. There's not a lot to it - pick your image file and
>>> then the device you want to write it to; it has some logic in it to not let
>>> you accidentally write to devices that aren't USB sticks.
>>>
>>> A few points:
>>>
>>> - I'm not sure very many people know this tool exists, so it's likely it's not
>>> being widely used. Having said that it is a nice simple UI that does the job.
>>>
>>> - It shares some code with Hob, but mostly not the bits with code quality
>>> issues, though it is still GTK+ 2 based.
>>>
>>> - It doesn't support the advanced SD card writing functionality that has been
>>> implented within wic over the last few releases, which is pretty important for
>>> devices where a special partition layout is expected by the bootloader.
>>>
>>> - Toaster can't really have this functionality in it because it's web based
>>> and the web server might not be running locally, so writing to a local USB
>>> stick or SD card isn't going to be practical from there; about all it could do
>>> is provide instructions on how to write the image once you've downloaded it.
>>>
>>> - I believe there are other equivalent tools out there that various distros
>>> use for taking a downloadable ISO image and writing it to a USB stick. I
>>> haven't done a survey to find out if if any of them work in quite the same way;
>>> I know some of them actually unpack the image and then re-create a filesystem
>>> on the device, which isn't the right thing for our images.
>>>
>>> - We do have a command-line equivalent in the form of scripts/contrib/ddimage
>>> in OE-Core. Of course it's command-line and thus less friendly but it does the
>>> job (and also has some safeguards against writing to the wrong device).
>>>
>>> So what do we do with this? We have two choices really:
>>>
>>> A) Drop bitbake/bin/imagewriter along with Hob; we could potentially
>>> resurrect it again later if desired
>>>
>>> B) Preserve it along with the shared modules that it requires
>>>
>>> Thoughts?
>>
>> Option A. There are USB writer tool in your favorite distros and OSes, and I have
>> seen people use those tools more often.
>
> Some platforms, e.g. Minnow, use their own image writing script (i.e. mkefidisk.sh). If there are other platforms which
> need some special tool that isn't generically available from the host and the hob tool could be made to accommodate them
> all, I'd prefer to see one tool that can do all of them instead of a bunch of tools, one for each platform.

As Paul mentioned, each platform seems to want to do this "their
own way" which is troublesome at best for embedded systems.  I think
it would be much better to maintain one way that works with what we
are building (OE based embedded devices) rather than relying on the
whims of others.  So, if it's not too hard, I'd prefer that this
ability be kept, even as a stand-alone script.

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

Re: [Openembedded-architecture] Standalone image writer

[Paul Eggleton]

On Mon, 29 Feb 2016 04:48:57 Gary Thomas wrote:
> On 02/29/2016 04:31 AM, Trevor Woerner wrote:
> > On 02/28/16 20:46, Khem Raj wrote:
> >>> On Feb 28, 2016, at 4:17 PM, Paul Eggleton
> >>> <paul.eggleton@linux.intel.com> wrote:
> >>> 
> >>> (changing subject line so people don't miss this slight tangent)
> >>> 
> >>> I'd almost completely forgotten, but the part of what we wrote for Hob
> >>> to
> >>> write images to a USB stick or SD card (bitbake/bin/image-writer) is
> >>> actually a standalone application. There's not a lot to it - pick your
> >>> image file and then the device you want to write it to; it has some
> >>> logic in it to not let you accidentally write to devices that aren't
> >>> USB sticks.
> >>> 
> >>> A few points:
> >>> 
> >>> - I'm not sure very many people know this tool exists, so it's likely
> >>> it's not being widely used. Having said that it is a nice simple UI
> >>> that does the job.
> >>> 
> >>> - It shares some code with Hob, but mostly not the bits with code
> >>> quality
> >>> issues, though it is still GTK+ 2 based.
> >>> 
> >>> - It doesn't support the advanced SD card writing functionality that has
> >>> been implented within wic over the last few releases, which is pretty
> >>> important for devices where a special partition layout is expected by
> >>> the bootloader.
> >>> 
> >>> - Toaster can't really have this functionality in it because it's web
> >>> based
> >>> and the web server might not be running locally, so writing to a local
> >>> USB
> >>> stick or SD card isn't going to be practical from there; about all it
> >>> could do is provide instructions on how to write the image once you've
> >>> downloaded it.
> >>> 
> >>> - I believe there are other equivalent tools out there that various
> >>> distros
> >>> use for taking a downloadable ISO image and writing it to a USB stick. I
> >>> haven't done a survey to find out if if any of them work in quite the
> >>> same way; I know some of them actually unpack the image and then
> >>> re-create a filesystem on the device, which isn't the right thing for
> >>> our images.
> >>> 
> >>> - We do have a command-line equivalent in the form of
> >>> scripts/contrib/ddimage in OE-Core. Of course it's command-line and
> >>> thus less friendly but it does the job (and also has some safeguards
> >>> against writing to the wrong device).
> >>> 
> >>> So what do we do with this? We have two choices really:
> >>> 
> >>> A) Drop bitbake/bin/imagewriter along with Hob; we could potentially
> >>> resurrect it again later if desired
> >>> 
> >>> B) Preserve it along with the shared modules that it requires
> >>> 
> >>> Thoughts?
> >> 
> >> Option A. There are USB writer tool in your favorite distros and OSes,
> >> and I have seen people use those tools more often.
> > 
> > Some platforms, e.g. Minnow, use their own image writing script (i.e.
> > mkefidisk.sh). If there are other platforms which need some special tool
> > that isn't generically available from the host and the hob tool could be
> > made to accommodate them all, I'd prefer to see one tool that can do all
> > of them instead of a bunch of tools, one for each platform.
>
> As Paul mentioned, each platform seems to want to do this "their
> own way" which is troublesome at best for embedded systems.  I think
> it would be much better to maintain one way that works with what we
> are building (OE based embedded devices) rather than relying on the
> whims of others.  So, if it's not too hard, I'd prefer that this
> ability be kept, even as a stand-alone script.

Well, arguably the "one way that works" is supposed to be wic as far as the 
actual image writing is concerned. There's a bug open to ensure we support all 
of the reference platforms [1], and I'd encourage anyone developing a BSP with 
unusual partition/formatting requirements to work out how those can be 
supported in wic if they aren't already so we can get away from these BSP-
specific classes and scripts.

There isn't a frontend UI for wic that I am aware of though - as I mentioned 
earlier image-writer has no support for it, it's just doing a straight dd to 
the device.

Cheers,
Paul

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8719

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Standalone image writer

[Barros Pena, Belen]

On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of Paul
Eggleton" <yocto-bounces@yoctoproject.org on behalf of
paul.eggleton@linux.intel.com> wrote:

>There isn't a frontend UI for wic that I am aware of though - as I
>mentioned 
>earlier image-writer has no support for it, it's just doing a straight dd
>to 
>the device.

We would really like to add support for wic at some point.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769

Maybe 2.1?

Cheers

Belén

Re: [Openembedded-architecture] Standalone image writer

[Paul Eggleton]

On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
> On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of Paul
> Eggleton" <yocto-bounces@yoctoproject.org on behalf of
> paul.eggleton@linux.intel.com> wrote:
> >There isn't a frontend UI for wic that I am aware of though - as I
> >mentioned earlier image-writer has no support for it, it's just doing a
> >straight dd to the device.
> 
> We would really like to add support for wic at some point.
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769

True, but that's a slightly different usage of wic - i.e. preparing the 
formatted image, which we should support. However, writing a formatted image 
to an SD card / USB stick isn't something you could practically do from a web-
based application I don't think - not without help from a local application at 
any rate.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Standalone image writer

[Giordon Stark]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

Hi all,

In a similar problem -- I find that the boot.bin file does not work out of
the box when I copy the files over to the SDCard to boot on a Xilinx board.
I end up having to open the SDK and generate a BOOT image myself using the
other files that were generated (u-boot, devicetree) with the SDK's
FSBL.elf. Is this a known problem or would a centralized solution for
creating the image solve this?

Giordon

On Mon, Feb 29, 2016 at 1:53 PM Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
> > On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of Paul
> > Eggleton" <yocto-bounces@yoctoproject.org on behalf of
> > paul.eggleton@linux.intel.com> wrote:
> > >There isn't a frontend UI for wic that I am aware of though - as I
> > >mentioned earlier image-writer has no support for it, it's just doing a
> > >straight dd to the device.
> >
> > We would really like to add support for wic at some point.
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769
>
> True, but that's a slightly different usage of wic - i.e. preparing the
> formatted image, which we should support. However, writing a formatted
> image
> to an SD card / USB stick isn't something you could practically do from a
> web-
> based application I don't think - not without help from a local
> application at
> any rate.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 2534 bytes --]

Re: [Openembedded-architecture] Standalone image writer

[Paul Eggleton]

Hi Giordon,

The image writer in question has no specific support for Xilinx boards. If 
you're having a problem relating to the Xilinx BSP and you don't get a 
response here then I'd suggest contacting the BSP maintainer(s).

Cheers,
Paul

On Mon, 29 Feb 2016 20:05:44 Giordon Stark wrote:
> Hi all,
> 
> In a similar problem -- I find that the boot.bin file does not work out of
> the box when I copy the files over to the SDCard to boot on a Xilinx board.
> I end up having to open the SDK and generate a BOOT image myself using the
> other files that were generated (u-boot, devicetree) with the SDK's
> FSBL.elf. Is this a known problem or would a centralized solution for
> creating the image solve this?
> 
> Giordon
> 
> On Mon, Feb 29, 2016 at 1:53 PM Paul Eggleton
> <paul.eggleton@linux.intel.com>
> wrote:
> > On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
> > > On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of Paul
> > > Eggleton" <yocto-bounces@yoctoproject.org on behalf of
> > > 
> > > paul.eggleton@linux.intel.com> wrote:
> > > >There isn't a frontend UI for wic that I am aware of though - as I
> > > >mentioned earlier image-writer has no support for it, it's just doing a
> > > >straight dd to the device.
> > > 
> > > We would really like to add support for wic at some point.
> > > 
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769
> > 
> > True, but that's a slightly different usage of wic - i.e. preparing the
> > formatted image, which we should support. However, writing a formatted
> > image
> > to an SD card / USB stick isn't something you could practically do from a
> > web-
> > based application I don't think - not without help from a local
> > application at
> > any rate.
> > 
> > Cheers,
> > Paul
> > 
> > --
> > 
> > Paul Eggleton
> > Intel Open Source Technology Centre
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [Openembedded-architecture] Standalone image writer

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

I think it depends on what kind of users we are targeting. I didn't even
know about the existence of this tool (heard but can't say I know anything
about it). And all the people I am in contact with use distro specific
tools. Maybe if we target less technical people or we just want a distro
unification tool simply for ease of use, it would make sense to keep it -
even though I don't really understand why this hard separation in between
wic and image burner. Whatever you generate, you need to burn so the
process is clear and could be unified as an option.
On 2 Mar 2016 10:18 pm, "Paul Eggleton" <paul.eggleton@linux.intel.com>
wrote:

> Hi Giordon,
>
> The image writer in question has no specific support for Xilinx boards. If
> you're having a problem relating to the Xilinx BSP and you don't get a
> response here then I'd suggest contacting the BSP maintainer(s).
>
> Cheers,
> Paul
>
> On Mon, 29 Feb 2016 20:05:44 Giordon Stark wrote:
> > Hi all,
> >
> > In a similar problem -- I find that the boot.bin file does not work out
> of
> > the box when I copy the files over to the SDCard to boot on a Xilinx
> board.
> > I end up having to open the SDK and generate a BOOT image myself using
> the
> > other files that were generated (u-boot, devicetree) with the SDK's
> > FSBL.elf. Is this a known problem or would a centralized solution for
> > creating the image solve this?
> >
> > Giordon
> >
> > On Mon, Feb 29, 2016 at 1:53 PM Paul Eggleton
> > <paul.eggleton@linux.intel.com>
> > wrote:
> > > On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
> > > > On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of
> Paul
> > > > Eggleton" <yocto-bounces@yoctoproject.org on behalf of
> > > >
> > > > paul.eggleton@linux.intel.com> wrote:
> > > > >There isn't a frontend UI for wic that I am aware of though - as I
> > > > >mentioned earlier image-writer has no support for it, it's just
> doing a
> > > > >straight dd to the device.
> > > >
> > > > We would really like to add support for wic at some point.
> > > >
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769
> > >
> > > True, but that's a slightly different usage of wic - i.e. preparing the
> > > formatted image, which we should support. However, writing a formatted
> > > image
> > > to an SD card / USB stick isn't something you could practically do
> from a
> > > web-
> > > based application I don't think - not without help from a local
> > > application at
> > > any rate.
> > >
> > > Cheers,
> > > Paul
> > >
> > > --
> > >
> > > Paul Eggleton
> > > Intel Open Source Technology Centre
> > > --
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 4364 bytes --]

Re: [Openembedded-architecture] Standalone image writer

[Philip Balister]

On 02/29/2016 02:52 PM, Paul Eggleton wrote:
> On Mon, 29 Feb 2016 11:27:15 Barros Pena, Belen wrote:
>> On 29/02/2016 08:12, "yocto-bounces@yoctoproject.org on behalf of Paul
>> Eggleton" <yocto-bounces@yoctoproject.org on behalf of
>> paul.eggleton@linux.intel.com> wrote:
>>> There isn't a frontend UI for wic that I am aware of though - as I
>>> mentioned earlier image-writer has no support for it, it's just doing a
>>> straight dd to the device.
>>
>> We would really like to add support for wic at some point.
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8769
> 
> True, but that's a slightly different usage of wic - i.e. preparing the 
> formatted image, which we should support. However, writing a formatted image 
> to an SD card / USB stick isn't something you could practically do from a web-
> based application I don't think - not without help from a local application at 
> any rate.

For writing the output of wic to an mmc card, I use wic. I believe it is
available as an Ubuntu package and works well on Fedora.

https://source.tizen.org/documentation/reference/bmaptool/bmap-tools-project

Philip

> 
> Cheers,
> Paul
> 

FW: Removing Hob for 2.1

[Barros Pena, Belen]

FYI

On 26/02/2016 03:49, "Paul Eggleton" <paul.eggleton@linux.intel.com> wrote:

>Hi folks,
>
>So we've been gearing up the Toaster web UI to replace the Hob (GTK+
>based) UI 
>for some time now; Hob has basically been on life support for the past
>few 
>releases. As of late last month in master, Toaster has the capability to
>select the packages in an image, removing the last thing that Hob could
>do 
>that Toaster couldn't. This means it's about time we looked at removing
>Hob - 
>particularly if we want to do so for the upcoming 2.1 release as we
>should 
>really do so within the M3 development timeframe which is almost over.
>
>To recap, the reasons why Hob ought to be removed include:
>
>- The code is tightly woven into BitBake, making it fragile. This means
>it 
>needs significant QA and maintenance on an ongoing basis.
>
>- Some of the implementation is not ideal; we'll be able to remove some
>cruft 
>from BitBake and OE-Core at the same time.
>
>- It's GTK+ 2 based, not the current GTK+ 3.
>
>- Toaster is now a much more capable UI and is being actively maintained
>
>I'm maintaining a list of things we would drop together with Hob, so I
>could 
>probably come up with a patchset - I just wanted to give people a heads
>up and 
>double check that this is something we indeed want to do in 2.1. Any
>comments?
>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre