Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: > On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh > wrote: > > Hi Maciej, > > > > There is already --size and --extra-space options. > > Can we get the same or similar result by just using them? Do we really > > need new option for similar purpose? > > --reserved-size serves a different purpose, it establishes an upper > bound on the size of a partition during layout. Unlike > --size/--extra-space does not depend on the size of the filesystem > image. > > For instance, assume I'm creating an image for SD card/eMMC with a > fixed partition layout (something simple: boot partition, primary & > secondary rootfs partitions, some data partition). Because future > system updates are delivered as filesystem image, I want to make sure > that there is exactly xxx MBs for my current and future rootfs images > (regardless of current image size). Neither --size nor --extra-space > can do that. I could use, say `--size 200 --overhead-factor 1`, but > this will needlessly create a 200MB rootfs image and if I happen to > cross the 200MB boundary I will not get an error. > > I had a private patch that added --fixed-size to enforce --size, but > that would still end up creating filesystem image to fill the whole > space. I didn't get the difference between enforcing partition size and below implementation. Can you elaborate a bit? > Another workaround we used until now was to create a filesystem image > manually and use fsimage source plugin. To get a fixed layout with > rootfs image that may grow/shrink between builds, you still need to > fiddle with --align (for instance, set it to 215040 to have the > partition start at 210MB offset). > Thanks for the explanations. I'm almost convinced. See my comments below. > > > > > > On Mon, Oct 17, 2016 at 03:06:18PM +0200, Maciej Borzecki wrote: > >> Added new option --reserved-size to wks. The option can be used to > >> indicate how much space should be reserved for a partition. This is > >> useful if the disk will be a subject to full filesystem image updates > >> and puts an upper limit of the size of filesystem images. > >> > >> The actual filesystem image may be smaller than the reserved space, thus > >> leaving some room for growth. If it is larger, an error will be raised. > >> > >> Signed-off-by: Maciej Borzecki > >> --- > >> scripts/lib/wic/help.py| 11 ++ > >> scripts/lib/wic/imager/direct.py | 3 ++- > >> scripts/lib/wic/ksparser.py| 1 + > >> scripts/lib/wic/partition.py | 1 + > >> scripts/lib/wic/utils/partitionedfs.py | 37 > >> +- > >> 5 files changed, 43 insertions(+), 10 deletions(-) > >> > >> diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > >> index > >> e5347ec4b7c900c68fc64351a5293e75de0672b3..1a5c7020ba0cdc5ef2e477a2b14360e09098a896 > >> 100644 > >> --- a/scripts/lib/wic/help.py > >> +++ b/scripts/lib/wic/help.py > >> @@ -646,6 +646,17 @@ DESCRIPTION > >> not specified, the size is in MB. > >> You do not need this option if you use --source. > >> > >> + --reserved-size: This option specifies that there should be > >> + at least that many bytes reserved for According to the code if partition size > reserved size wic will throw an error. This somehow conflicts with 'at least that many bytes' part of the description in my opinion. As far as I uderstood your code this parameter specifies hard upper limit for partition size, right? > >> + the partition during layout. This is useful > >> + when the target disk will be a subject > >> + to full system image updates in the future. > >> + Specifying --reserved-size ensures that > >> + there is extra space in the partition allowing > >> + for future growth of the file system stored > >> + inside. Value format is the same as for > >> + --size option. > >> + > >> --source: This option is a wic-specific option that names the > >> source of the data that will populate the > >> partition. The most common value for this option > >> diff --git a/scripts/lib/wic/imager/direct.py > >> b/scripts/lib/wic/imager/direct.py > >> index > >> edf5e5d2214f8e78b6c2a98d7f6cd45fcc0065c4..02e293b9d744b760fcdf17610505dafef3e164ad > >> 100644 > >> --- a/scripts/lib/wic/imager/direct.py > >> +++ b/scripts/lib/wic/imager/direct.py > >> @@ -301,7 +301,8 @@ class DirectImageCreator(BaseImageCreator): > >> no_table=part.no_table, > >> part_type=part.part_type, > >> uuid=part.uuid, > >> - system_id=p
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh wrote: > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh >> wrote: >> > Hi Maciej, >> > >> > There is already --size and --extra-space options. >> > Can we get the same or similar result by just using them? Do we really >> > need new option for similar purpose? >> >> --reserved-size serves a different purpose, it establishes an upper >> bound on the size of a partition during layout. Unlike >> --size/--extra-space does not depend on the size of the filesystem >> image. >> >> For instance, assume I'm creating an image for SD card/eMMC with a >> fixed partition layout (something simple: boot partition, primary & >> secondary rootfs partitions, some data partition). Because future >> system updates are delivered as filesystem image, I want to make sure >> that there is exactly xxx MBs for my current and future rootfs images >> (regardless of current image size). Neither --size nor --extra-space >> can do that. I could use, say `--size 200 --overhead-factor 1`, but >> this will needlessly create a 200MB rootfs image and if I happen to >> cross the 200MB boundary I will not get an error. >> >> I had a private patch that added --fixed-size to enforce --size, but >> that would still end up creating filesystem image to fill the whole >> space. > I didn't get the difference between enforcing partition size and below > implementation. Can you elaborate a bit? `--fixed-size` was something that I had added to my fork back in 2014, even before `--overhead-factor` came in. The problem is that depending on a project you might want to have more control over how partitions are laid out, or even need to have a fixed layout. Adding `--fixed-size` would had a similar effect to what `--overhead-factor 1` does right now. Combined with `--size` would ensure that rootfs is say, 200MB large. The downside was that wic would actually create a 200MB rootfs, something that is not really necessary. In fact, I only wanted to have 200MB gap so that I have some spare space for future updates (where update is just a rootfs image you dd to the partition). > >> Another workaround we used until now was to create a filesystem image >> manually and use fsimage source plugin. To get a fixed layout with >> rootfs image that may grow/shrink between builds, you still need to >> fiddle with --align (for instance, set it to 215040 to have the >> partition start at 210MB offset). >> > > Thanks for the explanations. I'm almost convinced. > > See my comments below. > >> > >> > >> > On Mon, Oct 17, 2016 at 03:06:18PM +0200, Maciej Borzecki wrote: >> >> Added new option --reserved-size to wks. The option can be used to >> >> indicate how much space should be reserved for a partition. This is >> >> useful if the disk will be a subject to full filesystem image updates >> >> and puts an upper limit of the size of filesystem images. >> >> >> >> The actual filesystem image may be smaller than the reserved space, thus >> >> leaving some room for growth. If it is larger, an error will be raised. >> >> >> >> Signed-off-by: Maciej Borzecki >> >> --- >> >> scripts/lib/wic/help.py| 11 ++ >> >> scripts/lib/wic/imager/direct.py | 3 ++- >> >> scripts/lib/wic/ksparser.py| 1 + >> >> scripts/lib/wic/partition.py | 1 + >> >> scripts/lib/wic/utils/partitionedfs.py | 37 >> >> +- >> >> 5 files changed, 43 insertions(+), 10 deletions(-) >> >> >> >> diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py >> >> index >> >> e5347ec4b7c900c68fc64351a5293e75de0672b3..1a5c7020ba0cdc5ef2e477a2b14360e09098a896 >> >> 100644 >> >> --- a/scripts/lib/wic/help.py >> >> +++ b/scripts/lib/wic/help.py >> >> @@ -646,6 +646,17 @@ DESCRIPTION >> >> not specified, the size is in MB. >> >> You do not need this option if you use --source. >> >> >> >> + --reserved-size: This option specifies that there should be >> >> + at least that many bytes reserved for > According to the code if partition size > reserved size wic will throw > an error. This somehow conflicts with 'at least that many bytes' part of the > description in my opinion. > > As far as I uderstood your code this parameter specifies hard upper > limit for partition size, right? Thanks, the wording is a bit off. I should rephrase it to 'that many bytes' or just state that it's an upper limit. > >> >> + the partition during layout. This is useful >> >> + when the target disk will be a subject >> >> + to full system image updates in the future. >> >> + Specifying --reserved-size ensures that >> >> + there is extra space in the partition allowing >> >> + for future growth of the file system stored >> >> +
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote:
> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh
> wrote:
> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote:
> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh
> >> wrote:
> >> > Hi Maciej,
> >> >
> >> > There is already --size and --extra-space options.
> >> > Can we get the same or similar result by just using them? Do we really
> >> > need new option for similar purpose?
> >>
> >> --reserved-size serves a different purpose, it establishes an upper
> >> bound on the size of a partition during layout. Unlike
> >> --size/--extra-space does not depend on the size of the filesystem
> >> image.
> >>
> >> For instance, assume I'm creating an image for SD card/eMMC with a
> >> fixed partition layout (something simple: boot partition, primary &
> >> secondary rootfs partitions, some data partition). Because future
> >> system updates are delivered as filesystem image, I want to make sure
> >> that there is exactly xxx MBs for my current and future rootfs images
> >> (regardless of current image size). Neither --size nor --extra-space
> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but
> >> this will needlessly create a 200MB rootfs image and if I happen to
> >> cross the 200MB boundary I will not get an error.
> >>
> >> I had a private patch that added --fixed-size to enforce --size, but
> >> that would still end up creating filesystem image to fill the whole
> >> space.
> > I didn't get the difference between enforcing partition size and below
> > implementation. Can you elaborate a bit?
>
> `--fixed-size` was something that I had added to my fork back in 2014,
> even before `--overhead-factor` came in. The problem is that depending
> on a project you might want to have more control over how partitions
> are laid out, or even need to have a fixed layout. Adding
> `--fixed-size` would had a similar effect to what `--overhead-factor
> 1` does right now. Combined with `--size` would ensure that rootfs is
> say, 200MB large. The downside was that wic would actually create a
> 200MB rootfs, something that is not really necessary. In fact, I only
> wanted to have 200MB gap so that I have some spare space for future
> updates (where update is just a rootfs image you dd to the partition).
>
Thanks for the explanations. Now I got it - reserved size is not a part
of partition, it's a gap between partitions.
What's the advantage of creating unusable gap over creating partition of
the same size that can be used? Even if that space is not needed it
doesn't harm to have it, does it?
> >> >>
> >> >> + --reserved-size: This option specifies that there should be
> >> >> + at least that many bytes reserved for
> > According to the code if partition size > reserved size wic will throw
> > an error. This somehow conflicts with 'at least that many bytes' part of the
> > description in my opinion.
> >
> > As far as I uderstood your code this parameter specifies hard upper
> > limit for partition size, right?
>
> Thanks, the wording is a bit off. I should rephrase it to 'that many
> bytes' or just state that it's an upper limit.
>
Upper limit is a wrong term here. I'm sorry for confusing you.
I proposed it because I misunderstood that it's not a partition size but a
reserved
space after partition. Anyway, I think above description should be
modified to explain the option in a clear way. Using ascii picture of
the partition layout would probably help to show what this option means.
> >> >> msger.debug("Assigned %s to %s%d, sectors range %d-%d size
> >> >> %d "
> >> >> -"sectors (%d bytes)." \
> >> >> +"sectors (%d bytes), reserved %d bytes." \
> >> >> % (part['mountpoint'], part['disk_name'],
> >> >> part['num'],
> >> >> - part['start'], part['start'] +
> >> >> part['size'] - 1,
> >> >> - part['size'], part['size'] *
> >> >> self.sector_size))
> >> >> + part['start'], disk['offset'] - 1,
> >> >> + part['size'], part['size'] *
> >> >> self.sector_size,
> >> >> + part['reserved_size'] *
> >> >> self.sector_size))
> > This will produce incorrect output about partition size as in reality
> > partition size will
> > be set to part['reserved_size'].
>
> I tried to avoid confusing the reader here. Partition size is one
> thing and reservation is another. That is why reservation is logged
> explicitly. Logging just the size would raise questions about why the
> partition has grown.
>
> Perhaps it makes sense to log reservation like this instead?
>
What about using 'reserved %d bytes of space after partition' or
something like that?
>part['reserved_size'] * self.sector_size if part['reserved_size']
> else part['size'] * self.sector_size
>
> >
> > "reser
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh wrote:
> On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote:
>> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh
>> wrote:
>> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote:
>> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh
>> >> wrote:
>> >> > Hi Maciej,
>> >> >
>> >> > There is already --size and --extra-space options.
>> >> > Can we get the same or similar result by just using them? Do we really
>> >> > need new option for similar purpose?
>> >>
>> >> --reserved-size serves a different purpose, it establishes an upper
>> >> bound on the size of a partition during layout. Unlike
>> >> --size/--extra-space does not depend on the size of the filesystem
>> >> image.
>> >>
>> >> For instance, assume I'm creating an image for SD card/eMMC with a
>> >> fixed partition layout (something simple: boot partition, primary &
>> >> secondary rootfs partitions, some data partition). Because future
>> >> system updates are delivered as filesystem image, I want to make sure
>> >> that there is exactly xxx MBs for my current and future rootfs images
>> >> (regardless of current image size). Neither --size nor --extra-space
>> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but
>> >> this will needlessly create a 200MB rootfs image and if I happen to
>> >> cross the 200MB boundary I will not get an error.
>> >>
>> >> I had a private patch that added --fixed-size to enforce --size, but
>> >> that would still end up creating filesystem image to fill the whole
>> >> space.
>> > I didn't get the difference between enforcing partition size and below
>> > implementation. Can you elaborate a bit?
>>
>> `--fixed-size` was something that I had added to my fork back in 2014,
>> even before `--overhead-factor` came in. The problem is that depending
>> on a project you might want to have more control over how partitions
>> are laid out, or even need to have a fixed layout. Adding
>> `--fixed-size` would had a similar effect to what `--overhead-factor
>> 1` does right now. Combined with `--size` would ensure that rootfs is
>> say, 200MB large. The downside was that wic would actually create a
>> 200MB rootfs, something that is not really necessary. In fact, I only
>> wanted to have 200MB gap so that I have some spare space for future
>> updates (where update is just a rootfs image you dd to the partition).
>>
> Thanks for the explanations. Now I got it - reserved size is not a part
> of partition, it's a gap between partitions.
I might have not been clear enough when explaining. It's not a gap,
it's just a container of size --reserved-size listed in MBR/GPT.
There's probably a filesystem inside but not necessarily.
Graphically it looks as like this:
--reserved-size
|--|
v v
+-+--+-+
|. stuff .|xx|. stuff .|
+-+--+-+
^ ^^
|-||
--size--extra-space
>
> What's the advantage of creating unusable gap over creating partition of
> the same size that can be used?
Just convenience.
> Even if that space is not needed it doesn't harm to have it, does it?
I have not seen any negative side effects.
>
>> >> >>
>> >> >> + --reserved-size: This option specifies that there should be
>> >> >> + at least that many bytes reserved for
>> > According to the code if partition size > reserved size wic will throw
>> > an error. This somehow conflicts with 'at least that many bytes' part of
>> > the
>> > description in my opinion.
>> >
>> > As far as I uderstood your code this parameter specifies hard upper
>> > limit for partition size, right?
>>
>> Thanks, the wording is a bit off. I should rephrase it to 'that many
>> bytes' or just state that it's an upper limit.
>>
> Upper limit is a wrong term here. I'm sorry for confusing you.
> I proposed it because I misunderstood that it's not a partition size but a
> reserved
> space after partition. Anyway, I think above description should be
> modified to explain the option in a clear way. Using ascii picture of
> the partition layout would probably help to show what this option means.
>
>> >> >> msger.debug("Assigned %s to %s%d, sectors range %d-%d
>> >> >> size %d "
>> >> >> -"sectors (%d bytes)." \
>> >> >> +"sectors (%d bytes), reserved %d bytes." \
>> >> >> % (part['mountpoint'], part['disk_name'],
>> >> >> part['num'],
>> >> >> - part['start'], part['start'] +
>> >> >> part['size'] - 1,
>> >> >> - part['size'], part['size'] *
>> >> >> self.sect
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: > On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh > wrote: > > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: > >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh > >> wrote: > >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: > >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh > >> >> wrote: > >> >> > Hi Maciej, > >> >> > > >> >> > There is already --size and --extra-space options. > >> >> > Can we get the same or similar result by just using them? Do we really > >> >> > need new option for similar purpose? > >> >> > >> >> --reserved-size serves a different purpose, it establishes an upper > >> >> bound on the size of a partition during layout. Unlike > >> >> --size/--extra-space does not depend on the size of the filesystem > >> >> image. > >> >> > >> >> For instance, assume I'm creating an image for SD card/eMMC with a > >> >> fixed partition layout (something simple: boot partition, primary & > >> >> secondary rootfs partitions, some data partition). Because future > >> >> system updates are delivered as filesystem image, I want to make sure > >> >> that there is exactly xxx MBs for my current and future rootfs images > >> >> (regardless of current image size). Neither --size nor --extra-space > >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but > >> >> this will needlessly create a 200MB rootfs image and if I happen to > >> >> cross the 200MB boundary I will not get an error. > >> >> > >> >> I had a private patch that added --fixed-size to enforce --size, but > >> >> that would still end up creating filesystem image to fill the whole > >> >> space. > >> > I didn't get the difference between enforcing partition size and below > >> > implementation. Can you elaborate a bit? > >> > >> `--fixed-size` was something that I had added to my fork back in 2014, > >> even before `--overhead-factor` came in. The problem is that depending > >> on a project you might want to have more control over how partitions > >> are laid out, or even need to have a fixed layout. Adding > >> `--fixed-size` would had a similar effect to what `--overhead-factor > >> 1` does right now. Combined with `--size` would ensure that rootfs is > >> say, 200MB large. The downside was that wic would actually create a > >> 200MB rootfs, something that is not really necessary. In fact, I only > >> wanted to have 200MB gap so that I have some spare space for future > >> updates (where update is just a rootfs image you dd to the partition). > >> > > Thanks for the explanations. Now I got it - reserved size is not a part > > of partition, it's a gap between partitions. > > I might have not been clear enough when explaining. It's not a gap, > it's just a container of size --reserved-size listed in MBR/GPT. > There's probably a filesystem inside but not necessarily. > Graphically it looks as like this: > > --reserved-size > |--| > v v > +-+--+-+ > |. stuff .|xx|. stuff .| > +-+--+-+ > ^ ^^ > |-|| >--size--extra-space > > Ah, I'm wrong again. It's a partition size limit, but it's not necessary formatted, right? It's only formatted if size == reserved_size. > > > > What's the advantage of creating unusable gap over creating partition of > > the same size that can be used? > > Just convenience. > What's the convenience of having extra space on partition that can't be used for data over having it formatted and used? > > Even if that space is not needed it doesn't harm to have it, does it? > > I have not seen any negative side effects. > I do. If user needs that reserved space it's impossible to get it without reformatting partition. The free space exists, but can't be used. -- Regards, Ed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 11:27 AM, Ed Bartosh wrote: > On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: >> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh >> wrote: >> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: >> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh >> >> wrote: >> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: >> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh >> >> >> wrote: >> >> >> > Hi Maciej, >> >> >> > >> >> >> > There is already --size and --extra-space options. >> >> >> > Can we get the same or similar result by just using them? Do we >> >> >> > really >> >> >> > need new option for similar purpose? >> >> >> >> >> >> --reserved-size serves a different purpose, it establishes an upper >> >> >> bound on the size of a partition during layout. Unlike >> >> >> --size/--extra-space does not depend on the size of the filesystem >> >> >> image. >> >> >> >> >> >> For instance, assume I'm creating an image for SD card/eMMC with a >> >> >> fixed partition layout (something simple: boot partition, primary & >> >> >> secondary rootfs partitions, some data partition). Because future >> >> >> system updates are delivered as filesystem image, I want to make sure >> >> >> that there is exactly xxx MBs for my current and future rootfs images >> >> >> (regardless of current image size). Neither --size nor --extra-space >> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but >> >> >> this will needlessly create a 200MB rootfs image and if I happen to >> >> >> cross the 200MB boundary I will not get an error. >> >> >> >> >> >> I had a private patch that added --fixed-size to enforce --size, but >> >> >> that would still end up creating filesystem image to fill the whole >> >> >> space. >> >> > I didn't get the difference between enforcing partition size and below >> >> > implementation. Can you elaborate a bit? >> >> >> >> `--fixed-size` was something that I had added to my fork back in 2014, >> >> even before `--overhead-factor` came in. The problem is that depending >> >> on a project you might want to have more control over how partitions >> >> are laid out, or even need to have a fixed layout. Adding >> >> `--fixed-size` would had a similar effect to what `--overhead-factor >> >> 1` does right now. Combined with `--size` would ensure that rootfs is >> >> say, 200MB large. The downside was that wic would actually create a >> >> 200MB rootfs, something that is not really necessary. In fact, I only >> >> wanted to have 200MB gap so that I have some spare space for future >> >> updates (where update is just a rootfs image you dd to the partition). >> >> >> > Thanks for the explanations. Now I got it - reserved size is not a part >> > of partition, it's a gap between partitions. >> >> I might have not been clear enough when explaining. It's not a gap, >> it's just a container of size --reserved-size listed in MBR/GPT. >> There's probably a filesystem inside but not necessarily. >> Graphically it looks as like this: >> >> --reserved-size >> |--| >> v v >> +-+--+-+ >> |. stuff .|xx|. stuff .| >> +-+--+-+ >> ^ ^^ >> |-|| >>--size--extra-space >> >> > Ah, I'm wrong again. It's a partition size limit, but it's not necessary > formatted, right? It's only formatted if size == reserved_size. > >> > >> > What's the advantage of creating unusable gap over creating partition of >> > the same size that can be used? >> >> Just convenience. >> > What's the convenience of having extra space on partition that can't be > used for data over having it formatted and used? > >> > Even if that space is not needed it doesn't harm to have it, does it? >> >> I have not seen any negative side effects. >> > I do. If user needs that reserved space it's impossible to get it without > reformatting partition. The free space exists, but can't be used. That's not the point and is not aligned with use case I'm trying to solve. My case is rather simple, I'm creating an image for SD card that is deployed in the field. In that particular case, there's a primary and a secondary (aka. active and inactive) rootfs partitions that are switched whenever a system update comes in. The update is a file system image that is copied over to the inactive partition, followed by a system reboot. What I need is the ability to set a certain size of a partition (say 100MB), regardless of current rootfs size (which may be, say 70MB). The remaining unused space sets an upper limit on how much the rootfs may grow in the future (in this example case, it's 30MB). RIght now the best I can do is to
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 12:24:55PM +0200, Maciej Borzęcki wrote: > On Tue, Oct 18, 2016 at 11:27 AM, Ed Bartosh > wrote: > > On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: > >> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh > >> wrote: > >> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: > >> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh > >> >> wrote: > >> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: > >> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh > >> >> >> wrote: > >> >> >> > Hi Maciej, > >> >> >> > > >> >> >> > There is already --size and --extra-space options. > >> >> >> > Can we get the same or similar result by just using them? Do we > >> >> >> > really > >> >> >> > need new option for similar purpose? > >> >> >> > >> >> >> --reserved-size serves a different purpose, it establishes an upper > >> >> >> bound on the size of a partition during layout. Unlike > >> >> >> --size/--extra-space does not depend on the size of the filesystem > >> >> >> image. > >> >> >> > >> >> >> For instance, assume I'm creating an image for SD card/eMMC with a > >> >> >> fixed partition layout (something simple: boot partition, primary & > >> >> >> secondary rootfs partitions, some data partition). Because future > >> >> >> system updates are delivered as filesystem image, I want to make sure > >> >> >> that there is exactly xxx MBs for my current and future rootfs images > >> >> >> (regardless of current image size). Neither --size nor --extra-space > >> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but > >> >> >> this will needlessly create a 200MB rootfs image and if I happen to > >> >> >> cross the 200MB boundary I will not get an error. > >> >> >> > >> >> >> I had a private patch that added --fixed-size to enforce --size, but > >> >> >> that would still end up creating filesystem image to fill the whole > >> >> >> space. > >> >> > I didn't get the difference between enforcing partition size and below > >> >> > implementation. Can you elaborate a bit? > >> >> > >> >> `--fixed-size` was something that I had added to my fork back in 2014, > >> >> even before `--overhead-factor` came in. The problem is that depending > >> >> on a project you might want to have more control over how partitions > >> >> are laid out, or even need to have a fixed layout. Adding > >> >> `--fixed-size` would had a similar effect to what `--overhead-factor > >> >> 1` does right now. Combined with `--size` would ensure that rootfs is > >> >> say, 200MB large. The downside was that wic would actually create a > >> >> 200MB rootfs, something that is not really necessary. In fact, I only > >> >> wanted to have 200MB gap so that I have some spare space for future > >> >> updates (where update is just a rootfs image you dd to the partition). > >> >> > >> > Thanks for the explanations. Now I got it - reserved size is not a part > >> > of partition, it's a gap between partitions. > >> > >> I might have not been clear enough when explaining. It's not a gap, > >> it's just a container of size --reserved-size listed in MBR/GPT. > >> There's probably a filesystem inside but not necessarily. > >> Graphically it looks as like this: > >> > >> --reserved-size > >> |--| > >> v v > >> +-+--+-+ > >> |. stuff .|xx|. stuff .| > >> +-+--+-+ > >> ^ ^^ > >> |-|| > >>--size--extra-space > >> > >> > > Ah, I'm wrong again. It's a partition size limit, but it's not necessary > > formatted, right? It's only formatted if size == reserved_size. > > > >> > > >> > What's the advantage of creating unusable gap over creating partition of > >> > the same size that can be used? > >> > >> Just convenience. > >> > > What's the convenience of having extra space on partition that can't be > > used for data over having it formatted and used? > > > >> > Even if that space is not needed it doesn't harm to have it, does it? > >> > >> I have not seen any negative side effects. > >> > > I do. If user needs that reserved space it's impossible to get it without > > reformatting partition. The free space exists, but can't be used. > > That's not the point and is not aligned with use case I'm trying to solve. > > My case is rather simple, I'm creating an image for SD card that is > deployed in the field. In that particular case, there's a primary and > a secondary (aka. active and inactive) rootfs partitions that are > switched whenever a system update comes in. The update is a file > system image that is copied over to the inactive partition, followed > by a system reboot. > > What I need is the ability to set a c
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 12:17 PM, Ed Bartosh wrote: > On Tue, Oct 18, 2016 at 12:24:55PM +0200, Maciej Borzęcki wrote: >> On Tue, Oct 18, 2016 at 11:27 AM, Ed Bartosh >> wrote: >> > On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: >> >> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh >> >> wrote: >> >> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: >> >> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh >> >> >> wrote: >> >> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: >> >> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh >> >> >> >> wrote: >> >> >> >> > Hi Maciej, >> >> >> >> > >> >> >> >> > There is already --size and --extra-space options. >> >> >> >> > Can we get the same or similar result by just using them? Do we >> >> >> >> > really >> >> >> >> > need new option for similar purpose? >> >> >> >> >> >> >> >> --reserved-size serves a different purpose, it establishes an upper >> >> >> >> bound on the size of a partition during layout. Unlike >> >> >> >> --size/--extra-space does not depend on the size of the filesystem >> >> >> >> image. >> >> >> >> >> >> >> >> For instance, assume I'm creating an image for SD card/eMMC with a >> >> >> >> fixed partition layout (something simple: boot partition, primary & >> >> >> >> secondary rootfs partitions, some data partition). Because future >> >> >> >> system updates are delivered as filesystem image, I want to make >> >> >> >> sure >> >> >> >> that there is exactly xxx MBs for my current and future rootfs >> >> >> >> images >> >> >> >> (regardless of current image size). Neither --size nor --extra-space >> >> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, but >> >> >> >> this will needlessly create a 200MB rootfs image and if I happen to >> >> >> >> cross the 200MB boundary I will not get an error. >> >> >> >> >> >> >> >> I had a private patch that added --fixed-size to enforce --size, but >> >> >> >> that would still end up creating filesystem image to fill the whole >> >> >> >> space. >> >> >> > I didn't get the difference between enforcing partition size and >> >> >> > below >> >> >> > implementation. Can you elaborate a bit? >> >> >> >> >> >> `--fixed-size` was something that I had added to my fork back in 2014, >> >> >> even before `--overhead-factor` came in. The problem is that depending >> >> >> on a project you might want to have more control over how partitions >> >> >> are laid out, or even need to have a fixed layout. Adding >> >> >> `--fixed-size` would had a similar effect to what `--overhead-factor >> >> >> 1` does right now. Combined with `--size` would ensure that rootfs is >> >> >> say, 200MB large. The downside was that wic would actually create a >> >> >> 200MB rootfs, something that is not really necessary. In fact, I only >> >> >> wanted to have 200MB gap so that I have some spare space for future >> >> >> updates (where update is just a rootfs image you dd to the partition). >> >> >> >> >> > Thanks for the explanations. Now I got it - reserved size is not a part >> >> > of partition, it's a gap between partitions. >> >> >> >> I might have not been clear enough when explaining. It's not a gap, >> >> it's just a container of size --reserved-size listed in MBR/GPT. >> >> There's probably a filesystem inside but not necessarily. >> >> Graphically it looks as like this: >> >> >> >> --reserved-size >> >> |--| >> >> v v >> >> +-+--+-+ >> >> |. stuff .|xx|. stuff .| >> >> +-+--+-+ >> >> ^ ^^ >> >> |-|| >> >>--size--extra-space >> >> >> >> >> > Ah, I'm wrong again. It's a partition size limit, but it's not necessary >> > formatted, right? It's only formatted if size == reserved_size. >> > >> >> > >> >> > What's the advantage of creating unusable gap over creating partition of >> >> > the same size that can be used? >> >> >> >> Just convenience. >> >> >> > What's the convenience of having extra space on partition that can't be >> > used for data over having it formatted and used? >> > >> >> > Even if that space is not needed it doesn't harm to have it, does it? >> >> >> >> I have not seen any negative side effects. >> >> >> > I do. If user needs that reserved space it's impossible to get it without >> > reformatting partition. The free space exists, but can't be used. >> >> That's not the point and is not aligned with use case I'm trying to solve. >> >> My case is rather simple, I'm creating an image for SD card that is >> deployed in the field. In that particular case, there's a primary and >> a secondary (aka. active and inactive) rootfs partitions that are >> switched whenev
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 01:07:48PM +0200, Maciej Borzęcki wrote: > On Tue, Oct 18, 2016 at 12:17 PM, Ed Bartosh > wrote: > > On Tue, Oct 18, 2016 at 12:24:55PM +0200, Maciej Borzęcki wrote: > >> On Tue, Oct 18, 2016 at 11:27 AM, Ed Bartosh > >> wrote: > >> > On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: > >> >> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh > >> >> wrote: > >> >> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: > >> >> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh > >> >> >> wrote: > >> >> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: > >> >> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh > >> >> >> >> wrote: > >> >> >> >> > Hi Maciej, > >> >> >> >> > > >> >> >> >> > There is already --size and --extra-space options. > >> >> >> >> > Can we get the same or similar result by just using them? Do we > >> >> >> >> > really > >> >> >> >> > need new option for similar purpose? > >> >> >> >> > >> >> >> >> --reserved-size serves a different purpose, it establishes an > >> >> >> >> upper > >> >> >> >> bound on the size of a partition during layout. Unlike > >> >> >> >> --size/--extra-space does not depend on the size of the filesystem > >> >> >> >> image. > >> >> >> >> > >> >> >> >> For instance, assume I'm creating an image for SD card/eMMC with a > >> >> >> >> fixed partition layout (something simple: boot partition, primary > >> >> >> >> & > >> >> >> >> secondary rootfs partitions, some data partition). Because future > >> >> >> >> system updates are delivered as filesystem image, I want to make > >> >> >> >> sure > >> >> >> >> that there is exactly xxx MBs for my current and future rootfs > >> >> >> >> images > >> >> >> >> (regardless of current image size). Neither --size nor > >> >> >> >> --extra-space > >> >> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, > >> >> >> >> but > >> >> >> >> this will needlessly create a 200MB rootfs image and if I happen > >> >> >> >> to > >> >> >> >> cross the 200MB boundary I will not get an error. > >> >> >> >> > >> >> >> >> I had a private patch that added --fixed-size to enforce --size, > >> >> >> >> but > >> >> >> >> that would still end up creating filesystem image to fill the > >> >> >> >> whole > >> >> >> >> space. > >> >> >> > I didn't get the difference between enforcing partition size and > >> >> >> > below > >> >> >> > implementation. Can you elaborate a bit? > >> >> >> > >> >> >> `--fixed-size` was something that I had added to my fork back in > >> >> >> 2014, > >> >> >> even before `--overhead-factor` came in. The problem is that > >> >> >> depending > >> >> >> on a project you might want to have more control over how partitions > >> >> >> are laid out, or even need to have a fixed layout. Adding > >> >> >> `--fixed-size` would had a similar effect to what `--overhead-factor > >> >> >> 1` does right now. Combined with `--size` would ensure that rootfs is > >> >> >> say, 200MB large. The downside was that wic would actually create a > >> >> >> 200MB rootfs, something that is not really necessary. In fact, I only > >> >> >> wanted to have 200MB gap so that I have some spare space for future > >> >> >> updates (where update is just a rootfs image you dd to the > >> >> >> partition). > >> >> >> > >> >> > Thanks for the explanations. Now I got it - reserved size is not a > >> >> > part > >> >> > of partition, it's a gap between partitions. > >> >> > >> >> I might have not been clear enough when explaining. It's not a gap, > >> >> it's just a container of size --reserved-size listed in MBR/GPT. > >> >> There's probably a filesystem inside but not necessarily. > >> >> Graphically it looks as like this: > >> >> > >> >> --reserved-size > >> >> |--| > >> >> v v > >> >> +-+--+-+ > >> >> |. stuff .|xx|. stuff .| > >> >> +-+--+-+ > >> >> ^ ^^ > >> >> |-|| > >> >>--size--extra-space > >> >> > >> >> > >> > Ah, I'm wrong again. It's a partition size limit, but it's not necessary > >> > formatted, right? It's only formatted if size == reserved_size. > >> > > >> >> > > >> >> > What's the advantage of creating unusable gap over creating partition > >> >> > of > >> >> > the same size that can be used? > >> >> > >> >> Just convenience. > >> >> > >> > What's the convenience of having extra space on partition that can't be > >> > used for data over having it formatted and used? > >> > > >> >> > Even if that space is not needed it doesn't harm to have it, does it? > >> >> > >> >> I have not seen any negative side effects. > >> >> > >> > I do. If user needs that reserved space it's im
Re: [OE-core] Two kmeta's not allowed for master?
On 2016-10-11 16:38, Nathan Rossi wrote: On Tue, Oct 11, 2016 at 11:15 PM, wrote: Hi, I was trying out how well 'master' branch compiles in our environment. We are using meta-xilinx and then we have custom BSP layer which bbappends linux-xlnx. When using meta-xilinx as standalone (w/o our BSP layer) I can get it tocompile. However when using it with combo meta-xilinx and our BSP we get failure on do_kernel_metadata due to missing scc files. It seems that there can no longer be two kmeta entries in SRC_URI. meta-xilinx's linux-xlnx.inc has: file://xilinx-base;type=kmeta;destsuffix=xilinx-base linux-xlnx has multiple kmeta sources. The one you mention here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-xlnx.inc#n13 And two more (added by a separate include): http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-xilinx-configs.inc#n8 So I don't think this is an issue due to the number of type=kmeta sources. Regards, Nathan our bbappend has: file://meta;type=kmeta;destsuffix=meta In krogoth this works fine. Is this expected change? I had to remove 'meta' from paths in KERNEL_FEATURES: -KERNEL_FEATURES_append += "meta/cfg/net/netfilter.scc" +KERNEL_FEATURES_append += "cfg/net/netfilter.scc" After this it seems to compile nicely with master. Thanks, Vesa Jääskeläinen -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Two kmeta's not allowed for master?
On Tue, Oct 18, 2016 at 2:56 PM, Vesa Jääskeläinen wrote: > On 2016-10-11 16:38, Nathan Rossi wrote: >> >> On Tue, Oct 11, 2016 at 11:15 PM, wrote: >>> >>> Hi, >>> >>> I was trying out how well 'master' branch compiles in our environment. >>> >>> We are using meta-xilinx and then we have custom BSP layer which >>> bbappends linux-xlnx. >>> >>> When using meta-xilinx as standalone (w/o our BSP layer) I can get it >>> tocompile. >>> >>> However when using it with combo meta-xilinx and our BSP we get failure >>> on do_kernel_metadata due to missing scc files. >>> >>> It seems that there can no longer be two kmeta entries in SRC_URI. >>> >>> meta-xilinx's linux-xlnx.inc has: >>> file://xilinx-base;type=kmeta;destsuffix=xilinx-base >> >> linux-xlnx has multiple kmeta sources. The one you mention here: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-xlnx.inc#n13 >> >> And two more (added by a separate include): >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-kernel/linux/linux-xilinx-configs.inc#n8 >> >> So I don't think this is an issue due to the number of type=kmeta sources. >> >> Regards, >> Nathan >> >>> our bbappend has: >>> file://meta;type=kmeta;destsuffix=meta >>> >>> In krogoth this works fine. >>> >>> Is this expected change? > > > I had to remove 'meta' from paths in KERNEL_FEATURES: > > -KERNEL_FEATURES_append += "meta/cfg/net/netfilter.scc" > +KERNEL_FEATURES_append += "cfg/net/netfilter.scc" Unrelated nit: += is never needed with _append (though an initial space would need to be added). See the note in http://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages. > > After this it seems to compile nicely with master. > > Thanks, > Vesa Jääskeläinen Cheers, Ulf -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] systemd-serialgetty: add dependency to agetty
On 18.10.2016 02:36, Khem Raj wrote:
On Oct 11, 2016, at 8:14 AM, Samuli Piippo wrote:
Signed-off-by: Samuli Piippo
---
meta/recipes-core/systemd/systemd-serialgetty.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb
b/meta/recipes-core/systemd/systemd-serialgetty.bb
index 768b130..c4e5310 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty.bb
+++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
@@ -38,7 +38,7 @@ do_install() {
fi
}
-RDEPENDS_${PN} = "systemd"
+RDEPENDS_${PN} = "systemd util-linux-agetty”
Does it need agetty specifically ? since there are other providers of getty as
well.
I wonder if its possible to use those too
serial-getty@.service is using /sbin/agetty, so currently it's the one.
systemd also has util-linux-agetty in RECOMMENDS, but that could perhaps
be removed.
# This is a machine specific file
FILES_${PN} = "${systemd_unitdir}/system/*.service ${sysconfdir}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 1:05 PM, Ed Bartosh wrote: > On Tue, Oct 18, 2016 at 01:07:48PM +0200, Maciej Borzęcki wrote: >> On Tue, Oct 18, 2016 at 12:17 PM, Ed Bartosh >> wrote: >> > On Tue, Oct 18, 2016 at 12:24:55PM +0200, Maciej Borzęcki wrote: >> >> On Tue, Oct 18, 2016 at 11:27 AM, Ed Bartosh >> >> wrote: >> >> > On Tue, Oct 18, 2016 at 11:24:14AM +0200, Maciej Borzęcki wrote: >> >> >> On Tue, Oct 18, 2016 at 10:38 AM, Ed Bartosh >> >> >> wrote: >> >> >> > On Tue, Oct 18, 2016 at 10:37:22AM +0200, Maciej Borzęcki wrote: >> >> >> >> On Tue, Oct 18, 2016 at 9:31 AM, Ed Bartosh >> >> >> >> wrote: >> >> >> >> > On Mon, Oct 17, 2016 at 04:46:00PM +0200, Maciej Borzęcki wrote: >> >> >> >> >> On Mon, Oct 17, 2016 at 3:22 PM, Ed Bartosh >> >> >> >> >> wrote: >> >> >> >> >> > Hi Maciej, >> >> >> >> >> > >> >> >> >> >> > There is already --size and --extra-space options. >> >> >> >> >> > Can we get the same or similar result by just using them? Do >> >> >> >> >> > we really >> >> >> >> >> > need new option for similar purpose? >> >> >> >> >> >> >> >> >> >> --reserved-size serves a different purpose, it establishes an >> >> >> >> >> upper >> >> >> >> >> bound on the size of a partition during layout. Unlike >> >> >> >> >> --size/--extra-space does not depend on the size of the >> >> >> >> >> filesystem >> >> >> >> >> image. >> >> >> >> >> >> >> >> >> >> For instance, assume I'm creating an image for SD card/eMMC with >> >> >> >> >> a >> >> >> >> >> fixed partition layout (something simple: boot partition, >> >> >> >> >> primary & >> >> >> >> >> secondary rootfs partitions, some data partition). Because future >> >> >> >> >> system updates are delivered as filesystem image, I want to make >> >> >> >> >> sure >> >> >> >> >> that there is exactly xxx MBs for my current and future rootfs >> >> >> >> >> images >> >> >> >> >> (regardless of current image size). Neither --size nor >> >> >> >> >> --extra-space >> >> >> >> >> can do that. I could use, say `--size 200 --overhead-factor 1`, >> >> >> >> >> but >> >> >> >> >> this will needlessly create a 200MB rootfs image and if I happen >> >> >> >> >> to >> >> >> >> >> cross the 200MB boundary I will not get an error. >> >> >> >> >> >> >> >> >> >> I had a private patch that added --fixed-size to enforce --size, >> >> >> >> >> but >> >> >> >> >> that would still end up creating filesystem image to fill the >> >> >> >> >> whole >> >> >> >> >> space. >> >> >> >> > I didn't get the difference between enforcing partition size and >> >> >> >> > below >> >> >> >> > implementation. Can you elaborate a bit? >> >> >> >> >> >> >> >> `--fixed-size` was something that I had added to my fork back in >> >> >> >> 2014, >> >> >> >> even before `--overhead-factor` came in. The problem is that >> >> >> >> depending >> >> >> >> on a project you might want to have more control over how partitions >> >> >> >> are laid out, or even need to have a fixed layout. Adding >> >> >> >> `--fixed-size` would had a similar effect to what `--overhead-factor >> >> >> >> 1` does right now. Combined with `--size` would ensure that rootfs >> >> >> >> is >> >> >> >> say, 200MB large. The downside was that wic would actually create a >> >> >> >> 200MB rootfs, something that is not really necessary. In fact, I >> >> >> >> only >> >> >> >> wanted to have 200MB gap so that I have some spare space for future >> >> >> >> updates (where update is just a rootfs image you dd to the >> >> >> >> partition). >> >> >> >> >> >> >> > Thanks for the explanations. Now I got it - reserved size is not a >> >> >> > part >> >> >> > of partition, it's a gap between partitions. >> >> >> >> >> >> I might have not been clear enough when explaining. It's not a gap, >> >> >> it's just a container of size --reserved-size listed in MBR/GPT. >> >> >> There's probably a filesystem inside but not necessarily. >> >> >> Graphically it looks as like this: >> >> >> >> >> >> --reserved-size >> >> >> |--| >> >> >> v v >> >> >> +-+--+-+ >> >> >> |. stuff .|xx|. stuff .| >> >> >> +-+--+-+ >> >> >> ^ ^^ >> >> >> |-|| >> >> >>--size--extra-space >> >> >> >> >> >> >> >> > Ah, I'm wrong again. It's a partition size limit, but it's not necessary >> >> > formatted, right? It's only formatted if size == reserved_size. >> >> > >> >> >> > >> >> >> > What's the advantage of creating unusable gap over creating >> >> >> > partition of >> >> >> > the same size that can be used? >> >> >> >> >> >> Just convenience. >> >> >> >> >> > What's the convenience of having extra space on partition that can't be >> >> > used for data over having it formatted and used
Re: [OE-core] [meta-oe][PATCH] systemd-serialgetty: add dependency to agetty
> On Oct 18, 2016, at 3:00 AM, Samuli Piippo wrote:
>
>> On 18.10.2016 02:36, Khem Raj wrote:
>>
>>> On Oct 11, 2016, at 8:14 AM, Samuli Piippo wrote:
>>>
>>> Signed-off-by: Samuli Piippo
>>> ---
>>> meta/recipes-core/systemd/systemd-serialgetty.bb | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> b/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> index 768b130..c4e5310 100644
>>> --- a/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> +++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> @@ -38,7 +38,7 @@ do_install() {
>>>fi
>>> }
>>>
>>> -RDEPENDS_${PN} = "systemd"
>>> +RDEPENDS_${PN} = "systemd util-linux-agetty”
>>
>> Does it need agetty specifically ? since there are other providers of getty
>> as well.
>> I wonder if its possible to use those too
>
> serial-getty@.service is using /sbin/agetty, so currently it's the one.
> systemd also has util-linux-agetty in RECOMMENDS, but that could perhaps be
> removed.
Hmm recommends is probably appropriate for this recipe too so it can be added
to bad recommendations if needed
>
>>
>>>
>>> # This is a machine specific file
>>> FILES_${PN} = "${systemd_unitdir}/system/*.service ${sysconfdir}"
>>> --
>>> 1.9.1
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] systemd-serialgetty: add dependency to agetty
> On Oct 18, 2016, at 3:00 AM, Samuli Piippo wrote:
>
>> On 18.10.2016 02:36, Khem Raj wrote:
>>
>>> On Oct 11, 2016, at 8:14 AM, Samuli Piippo wrote:
>>>
>>> Signed-off-by: Samuli Piippo
>>> ---
>>> meta/recipes-core/systemd/systemd-serialgetty.bb | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> b/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> index 768b130..c4e5310 100644
>>> --- a/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> +++ b/meta/recipes-core/systemd/systemd-serialgetty.bb
>>> @@ -38,7 +38,7 @@ do_install() {
>>>fi
>>> }
>>>
>>> -RDEPENDS_${PN} = "systemd"
>>> +RDEPENDS_${PN} = "systemd util-linux-agetty”
>>
>> Does it need agetty specifically ? since there are other providers of getty
>> as well.
>> I wonder if its possible to use those too
>
> serial-getty@.service is using /sbin/agetty, so currently it's the one.
> systemd also has util-linux-agetty in RECOMMENDS, but that could perhaps be
> removed.
I see, in this case its fine however it means we need to edit out more if not
using a Getty
>
>>
>>>
>>> # This is a machine specific file
>>> FILES_${PN} = "${systemd_unitdir}/system/*.service ${sysconfdir}"
>>> --
>>> 1.9.1
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 4:24 PM, Ed Bartosh wrote: > On Tue, Oct 18, 2016 at 03:59:23PM +0200, Maciej Borzęcki wrote: >> >> >> >> > What's the advantage of creating unusable gap over creating >> >> >> >> > partition of >> >> >> >> > the same size that can be used? >> >> >> >> >> >> >> >> Just convenience. >> >> >> >> >> >> >> > What's the convenience of having extra space on partition that can't >> >> >> > be >> >> >> > used for data over having it formatted and used? >> >> >> > >> >> >> >> > Even if that space is not needed it doesn't harm to have it, does >> >> >> >> > it? >> >> >> >> >> >> >> >> I have not seen any negative side effects. >> >> >> >> >> >> >> > I do. If user needs that reserved space it's impossible to get it >> >> >> > without >> >> >> > reformatting partition. The free space exists, but can't be used. >> >> >> >> >> >> That's not the point and is not aligned with use case I'm trying to >> >> >> solve. >> >> >> >> >> >> My case is rather simple, I'm creating an image for SD card that is >> >> >> deployed in the field. In that particular case, there's a primary and >> >> >> a secondary (aka. active and inactive) rootfs partitions that are >> >> >> switched whenever a system update comes in. The update is a file >> >> >> system image that is copied over to the inactive partition, followed >> >> >> by a system reboot. >> >> >> >> >> >> What I need is the ability to set a certain size of a partition (say >> >> >> 100MB), regardless of current rootfs size (which may be, say 70MB). >> >> >> The remaining unused space sets an upper limit on how much the rootfs >> >> >> may grow in the future (in this example case, it's 30MB). RIght now >> >> >> the best I can do is to describe a partition like this: `part / >> >> >> --source rootfs --size 100MB --overhead-factor 1`, hoping that if >> >> >> rootfs grows beyond 100MB I will somehow still be able to catch that >> >> >> and that the future images remain size compatible. >> >> >> >> >> >> The resulting filesystem inside the partition is larger than what >> >> >> IMAGE_CMD (ex. IMAGE_CMD_ext4) would give me, because of explicit >> >> >> --size in kickstart. I would prefer to have something comparable in >> >> >> size just to avoid later surprises, what implies using defaults. >> >> >> However, using defaults, means that I cannot control the layout >> >> >> because it will likely change each time rootfs size gets changed. >> >> >> There is no `--fixed-size` or other option to enforce specific size. >> >> >> >> >> >> Summing up, a simple use case that cannot be currently solved using >> >> >> wic. >> >> >> >> >> >> BTW. actually we're missing an ability to enforce --size (i.e. >> >> >> --fixed-size?) and a method passing an explicit partition offset >> >> >> inside the disk image (something useful for `--source rawcopy >> >> >> --no-table` partitions, currently solved with `--align`). >> >> >> >> >> > I undertood the problem and I agree that wic doesn't provide a solution. >> >> > >> >> > However, instead of making unformatted space I'd propose to format it, >> >> > i.e. to have --max-size option that would confict with --size and >> >> > specify upper size limit for the partition. All partition will be >> >> > formatted and available for data. This is identical to --fixed-size >> >> > option >> >> > you've described. This approach would solve the problem you're >> >> > addressing and it would also make additional space usable. >> >> > >> >> > I'd also suggest to rename --size to --min-size and make --size >> >> > deprecated. >> >> > >> >> > Does this make sense to you? >> >> >> >> No strong opinions here, just that deprecating --size might current >> >> users uneasy. >> >> >> > By deprecting --size I didn't mean removing it completely. We can just >> > print a warning suggesting usage of other options. >> > >> >> Perhaps --max-size could be a boolean switch? We could just name it >> >> --fixed-size (bool, defaults to False), with semantics that if >> >> --fixed-size is provided, the partition will have size --size, >> >> occurrence of --overhead-factor or --extra-space will raise an error. >> >> >> > That would work too, but it looks a bit confusing to me to have 2 different >> > types of size-related options. >> >> Ok, but now we would have --min-size (previously known as --size) and >> --size (or --max-size?). That's still 2 size related options plus a >> deprecation warning. >> > > I agree, it doesn't look good. Moreover --max-size doesn't make it > clear that partition will be this size. It rather suggests that partition > can be this size or less. > > So, we have --size which is actually minimum partition size, we have > couple of options to extend partition size (--overhead-factor and > --extra-space), but we don't have ability to set upper limit for partition > size. > > OK, let's agree on using --fixed-size(int) > Using --fixed-size with any of --size or --overhead-factor or --extra-space > options should raise ks parser error. If ro
Re: [OE-core] [PATCH] wic: add --reserved-size wks option
On Tue, Oct 18, 2016 at 03:59:23PM +0200, Maciej Borzęcki wrote: > >> >> >> > What's the advantage of creating unusable gap over creating > >> >> >> > partition of > >> >> >> > the same size that can be used? > >> >> >> > >> >> >> Just convenience. > >> >> >> > >> >> > What's the convenience of having extra space on partition that can't > >> >> > be > >> >> > used for data over having it formatted and used? > >> >> > > >> >> >> > Even if that space is not needed it doesn't harm to have it, does > >> >> >> > it? > >> >> >> > >> >> >> I have not seen any negative side effects. > >> >> >> > >> >> > I do. If user needs that reserved space it's impossible to get it > >> >> > without > >> >> > reformatting partition. The free space exists, but can't be used. > >> >> > >> >> That's not the point and is not aligned with use case I'm trying to > >> >> solve. > >> >> > >> >> My case is rather simple, I'm creating an image for SD card that is > >> >> deployed in the field. In that particular case, there's a primary and > >> >> a secondary (aka. active and inactive) rootfs partitions that are > >> >> switched whenever a system update comes in. The update is a file > >> >> system image that is copied over to the inactive partition, followed > >> >> by a system reboot. > >> >> > >> >> What I need is the ability to set a certain size of a partition (say > >> >> 100MB), regardless of current rootfs size (which may be, say 70MB). > >> >> The remaining unused space sets an upper limit on how much the rootfs > >> >> may grow in the future (in this example case, it's 30MB). RIght now > >> >> the best I can do is to describe a partition like this: `part / > >> >> --source rootfs --size 100MB --overhead-factor 1`, hoping that if > >> >> rootfs grows beyond 100MB I will somehow still be able to catch that > >> >> and that the future images remain size compatible. > >> >> > >> >> The resulting filesystem inside the partition is larger than what > >> >> IMAGE_CMD (ex. IMAGE_CMD_ext4) would give me, because of explicit > >> >> --size in kickstart. I would prefer to have something comparable in > >> >> size just to avoid later surprises, what implies using defaults. > >> >> However, using defaults, means that I cannot control the layout > >> >> because it will likely change each time rootfs size gets changed. > >> >> There is no `--fixed-size` or other option to enforce specific size. > >> >> > >> >> Summing up, a simple use case that cannot be currently solved using wic. > >> >> > >> >> BTW. actually we're missing an ability to enforce --size (i.e. > >> >> --fixed-size?) and a method passing an explicit partition offset > >> >> inside the disk image (something useful for `--source rawcopy > >> >> --no-table` partitions, currently solved with `--align`). > >> >> > >> > I undertood the problem and I agree that wic doesn't provide a solution. > >> > > >> > However, instead of making unformatted space I'd propose to format it, > >> > i.e. to have --max-size option that would confict with --size and > >> > specify upper size limit for the partition. All partition will be > >> > formatted and available for data. This is identical to --fixed-size > >> > option > >> > you've described. This approach would solve the problem you're > >> > addressing and it would also make additional space usable. > >> > > >> > I'd also suggest to rename --size to --min-size and make --size > >> > deprecated. > >> > > >> > Does this make sense to you? > >> > >> No strong opinions here, just that deprecating --size might current > >> users uneasy. > >> > > By deprecting --size I didn't mean removing it completely. We can just > > print a warning suggesting usage of other options. > > > >> Perhaps --max-size could be a boolean switch? We could just name it > >> --fixed-size (bool, defaults to False), with semantics that if > >> --fixed-size is provided, the partition will have size --size, > >> occurrence of --overhead-factor or --extra-space will raise an error. > >> > > That would work too, but it looks a bit confusing to me to have 2 different > > types of size-related options. > > Ok, but now we would have --min-size (previously known as --size) and > --size (or --max-size?). That's still 2 size related options plus a > deprecation warning. > I agree, it doesn't look good. Moreover --max-size doesn't make it clear that partition will be this size. It rather suggests that partition can be this size or less. So, we have --size which is actually minimum partition size, we have couple of options to extend partition size (--overhead-factor and --extra-space), but we don't have ability to set upper limit for partition size. OK, let's agree on using --fixed-size(int) Using --fixed-size with any of --size or --overhead-factor or --extra-space options should raise ks parser error. If rootfs size is bigger than --fixed-size wic should raise an error too. Any other opinions? -- Regards, Ed -- ___ Openembedded-
Re: [OE-core] [PATCH 0/2] Re-add piglit to sdk images
On 2016-10-14 02:31 PM, Jussi Kukkonen wrote: Piglit was removed because the current version was making sdk images too large. This patchset reduces the installed size by 1.5GB and adds piglit back to core-tools-testapps. Running piglit still requires the same amount of space so in practice this is useful for installed images only. Q: Do I need to declare a runtime dependency that typically comes from busybox (tar)? Yes, because some people try to eliminate busybox from their image. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane.bbclass: Additional "mips" and "mipsel" machine definitions
yes, good point. I will resend the patch with an updated commit
message.
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Monday, October 17, 2016 4:38 PM
> To: Bystricky, Juro
> Cc: openembedded-core@lists.openembedded.org; jurobystri...@hotmail.com
> Subject: Re: [OE-core] [PATCH] insane.bbclass: Additional "mips" and
> "mipsel" machine definitions
>
>
> > On Oct 11, 2016, at 9:56 AM, Juro Bystricky
> wrote:
> >
> > Add "mips" and "mipsel" to "machdata" table.
> > Although there is a way to add entries to the "machdata" table
> > from a BSP without modifying the insane.bbclass directly, MIPS is
> > already supported in poky and as such the relevant entries should be
> > present in insane.bbclass.
>
> perhaps say s/poky/openembedded-core/ here since thats where the patch
> is going to go.
>
> >
> > Signed-off-by: Juro Bystricky
> > ---
> > meta/classes/insane.bbclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> > index b347638..21c5cda 100644
> > --- a/meta/classes/insane.bbclass
> > +++ b/meta/classes/insane.bbclass
> > @@ -66,6 +66,8 @@ def package_qa_get_machine_dict(d):
> > "i586" : (3, 0,0, True,
> 32),
> > "x86_64": (62, 0,0, True,
> 64),
> > "epiphany": (4643, 0,0, True,
> 32),
> > +"mips": ( 8, 0,0, False,
> 32),
> > +"mipsel": ( 8, 0,0, True,
> 32),
> > },
> > "linux" : {
> > "aarch64" : (183,0,0, True,
> 64),
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] image_types: Add support for lzo compressed initial ramdisk
Signed-off-by: Vesa Jääskeläinen
---
meta/classes/image_types.bbclass | 4 +++-
meta/classes/image_types_uboot.bbclass | 5 -
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 772cb35..b5eea0e 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -328,13 +328,14 @@ IMAGE_TYPES = " \
# CONVERSION_CMD/DEPENDS.
COMPRESSIONTYPES ?= ""
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum
sha256sum sha384sum sha512sum bmap ${COMPRESSIONTYPES}"
CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS}
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.xz"
CONVERSION_CMD_lz4 = "lz4 -9 -z ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_lz4_legacy = "lz4 -9 -z -l
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
+CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
@@ -349,6 +350,7 @@ CONVERSION_DEPENDS_gz = ""
CONVERSION_DEPENDS_bz2 = "pbzip2-native"
CONVERSION_DEPENDS_xz = "xz-native"
CONVERSION_DEPENDS_lz4 = "lz4-native"
+CONVERSION_DEPENDS_lzo = "lzop-native"
CONVERSION_DEPENDS_zip = "zip-native"
CONVERSION_DEPENDS_sum = "mtd-utils-native"
CONVERSION_DEPENDS_bmap = "bmap-tools-native"
diff --git a/meta/classes/image_types_uboot.bbclass
b/meta/classes/image_types_uboot.bbclass
index 49028fa..5dfa392 100644
--- a/meta/classes/image_types_uboot.bbclass
+++ b/meta/classes/image_types_uboot.bbclass
@@ -8,7 +8,7 @@ oe_mkimage () {
fi
}
-CONVERSIONTYPES += "gz.u-boot bz2.u-boot lz4.u-boot lzma.u-boot u-boot"
+CONVERSIONTYPES += "gz.u-boot bz2.u-boot lz4.u-boot lzma.u-boot lzo.u-boot
u-boot"
CONVERSION_DEPENDS_u-boot = "u-boot-mkimage-native"
CONVERSION_CMD_u-boot = "oe_mkimage ${IMAGE_NAME}.rootfs.${type} none"
@@ -25,5 +25,8 @@ CONVERSION_CMD_lz4.u-boot =
"${CONVERSION_CMD_lz4_legacy}; oe_mkimage ${IMA
CONVERSION_DEPENDS_lzma.u-boot = "u-boot-mkimage-native"
CONVERSION_CMD_lzma.u-boot = "${CONVERSION_CMD_lzma}; oe_mkimage
${IMAGE_NAME}.rootfs.${type}.lzma lzma clean"
+CONVERSION_DEPENDS_lzo.u-boot = "u-boot-mkimage-native"
+CONVERSION_CMD_lzo.u-boot = "${CONVERSION_CMD_lzo}; oe_mkimage
${IMAGE_NAME}.rootfs.${type}.lzo lzo clean"
+
IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot ext2.lzma.u-boot
ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot"
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] image_types: Add support to compress initramfs with lz4
Changed to use lz4 as lz4c seems to be deprecated.
Removed use of redirection in favor of using output file.
As Linux kernel supports only legacy format for initial ramdisk add
COMPRESS_CMD_lz4_legacy mode in case some users are using newer format.
Signed-off-by: Vesa Jääskeläinen
---
meta/classes/image_types.bbclass | 3 ++-
meta/classes/image_types_uboot.bbclass | 5 -
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index a7fffbc..772cb35 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -333,7 +333,8 @@ CONVERSION_CMD_lzma = "lzma -k -f -7
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS}
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.xz"
-CONVERSION_CMD_lz4 = "lz4c -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
+CONVERSION_CMD_lz4 = "lz4 -9 -z ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
+CONVERSION_CMD_lz4_legacy = "lz4 -9 -z -l
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL}
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
CONVERSION_CMD_md5sum = "md5sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.md5sum"
diff --git a/meta/classes/image_types_uboot.bbclass
b/meta/classes/image_types_uboot.bbclass
index 6c8c1ff..49028fa 100644
--- a/meta/classes/image_types_uboot.bbclass
+++ b/meta/classes/image_types_uboot.bbclass
@@ -8,7 +8,7 @@ oe_mkimage () {
fi
}
-CONVERSIONTYPES += "gz.u-boot bz2.u-boot lzma.u-boot u-boot"
+CONVERSIONTYPES += "gz.u-boot bz2.u-boot lz4.u-boot lzma.u-boot u-boot"
CONVERSION_DEPENDS_u-boot = "u-boot-mkimage-native"
CONVERSION_CMD_u-boot = "oe_mkimage ${IMAGE_NAME}.rootfs.${type} none"
@@ -19,6 +19,9 @@ CONVERSION_CMD_gz.u-boot = "${CONVERSION_CMD_gz};
oe_mkimage ${IMAGE_NAME}.
CONVERSION_DEPENDS_bz2.u-boot = "u-boot-mkimage-native"
CONVERSION_CMD_bz2.u-boot = "${CONVERSION_CMD_bz2}; oe_mkimage
${IMAGE_NAME}.rootfs.${type}.bz2 bzip2 clean"
+CONVERSION_DEPENDS_lz4.u-boot = "u-boot-mkimage-native"
+CONVERSION_CMD_lz4.u-boot = "${CONVERSION_CMD_lz4_legacy}; oe_mkimage
${IMAGE_NAME}.rootfs.${type}.lz4 lz4 clean"
+
CONVERSION_DEPENDS_lzma.u-boot = "u-boot-mkimage-native"
CONVERSION_CMD_lzma.u-boot = "${CONVERSION_CMD_lzma}; oe_mkimage
${IMAGE_NAME}.rootfs.${type}.lzma lzma clean"
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-arch.bbclass: Add xtensa and arc into valid_archs table
The single purpose of "map_kernel_arch" is to set export ARCH = "arch_xxx" Presently, we must set ARCH even when building baremetal toolchains only, without any need to build kernel. However, in this case we may encounter a bogus error such as "cannot map arch_xxx to a linux kernel architecture". The simplest way to avoid this is to place arch_xxx into the table "valid_archs". (That was the main reason for the patch). A better but more complex way would be to modify the code so map_kernel_arch is not called at all when NOT building kernel or kernel modules. This would also allow building baremetal cross-toolchains for arches that don't have Linux kernels at all. Another way to consider is perhaps just getting rid of the table "valid_archs" entirely. "map_kernel_arch" maps arch_aaa -> arch_xxx for some cases. If there is no explicit mapping, then it could simply map arch_aaa->arch_aaa resulting in export ARCH="arch_aaa" There would be no error generated. If ARCH is not a valid arch for a Linux kernel, we would encounter a build error at some point. But that, I believe is the same case now if we try to build a kernel with a valid kernel ARCH but not supported actively in OE or extended OE ecosystem. > -Original Message- > From: Khem Raj [mailto:raj.k...@gmail.com] > Sent: Monday, October 17, 2016 4:40 PM > To: Bystricky, Juro > Cc: openembedded-core@lists.openembedded.org; jurobystri...@hotmail.com > Subject: Re: [OE-core] [PATCH] kernel-arch.bbclass: Add xtensa and arc into > valid_archs table > > > > On Oct 11, 2016, at 9:31 AM, Juro Bystricky > wrote: > > > > Both "arc" and "xtensa" are valid Linux architectures, add > > them into valid_archs table. > > > > Signed-off-by: Juro Bystricky > > --- > > meta/classes/kernel-arch.bbclass | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel- > arch.bbclass > > index 8a4bef1..ea976c6 100644 > > --- a/meta/classes/kernel-arch.bbclass > > +++ b/meta/classes/kernel-arch.bbclass > > @@ -14,7 +14,7 @@ valid_archs = "alpha cris ia64 \ > >parisc s390 v850 \ > >avr32 blackfin \ > >microblaze \ > > - nios2" > > + nios2 arc xtensa” > > there parisc etc as well so in essence patch is ok but I wonder if we > should > remove the arches we dont actively support in OE or extended OE ecosystem. > > > > > def map_kernel_arch(a, d): > > import re > > -- > > 2.7.4 > > > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] insane.bbclass: Additional "mips" and "mipsel" machine definitions
Add "mips" and "mipsel" to "machdata" table.
Although there is a way to add entries to the "machdata" table
from a BSP without modifying the insane.bbclass directly, MIPS is
already supported in openembedded-core and as such the relevant entries
should be present in insane.bbclass.
Signed-off-by: Juro Bystricky
---
meta/classes/insane.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index b347638..21c5cda 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -66,6 +66,8 @@ def package_qa_get_machine_dict(d):
"i586" : (3, 0,0, True,
32),
"x86_64": (62, 0,0, True,
64),
"epiphany": (4643, 0,0, True,
32),
+"mips": ( 8, 0,0, False,
32),
+"mipsel": ( 8, 0,0, True,
32),
},
"linux" : {
"aarch64" : (183,0,0, True,
64),
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/9] selftest: skip some devtool tests when distro is poky-tiny due to missing libx11
On Mon, 2016-10-17 at 10:19 -0500, Leonardo Sandoval wrote:
>
>
>
>
>
>
> On 10/17/2016 06:42 AM, Burton, Ross
> wrote:
>
>
>
> >
> >
> >
> > > > On 14 October 2016 at 17:40,
> > wrote:
> >
> > >
> > > def test_devtool_add_fetch_git(self):
> > >
> > > - # Fetch source
> > >
> > > + if self.distro == 'poky-tiny':
> > >
> > > + self.skipTest('libmatchbox2 is not
> > > > > > buildable with poky-tiny because it requires a
libx11
> > > provider')
> > >
> > > > > > tempdir =
tempfile.mkdtemp(prefix='devtoolqa')
> > >
> > > self.track_for_cleanup(tempdir)
> > >
> > > > > > url =
'git://git.yoctoproject.org/libmatchbox'
> > >
> > >
> >
> >
> >
> >
> > Changing the test to use a recipe that doesn't require a
> > > > distro feature that many distros disable seems like a
more
> > sustainable fix.
> >
> >
> >
> >
> >
> >
> >
> Which recipe do you think would be more generic?
Something in the minimal image which doesn't rely on DISTRO_FEATURES
which aren't in the default distro.
Thanks,
Joshua
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/9] selftest: skip two bbtest tests depending on distro
On Mon, 2016-10-17 at 11:04 -0500, Leonardo Sandoval wrote:
>
> On 10/17/2016 02:08 AM, Joshua Lock wrote:
> >
> > On Fri, 2016-10-14 at 11:40 -0500,
> > leonardo.sandoval.gonza...@linux.intel.com wrote:
> > >
> > > From: Leonardo Sandoval > > om>
> > >
> > > There are two bbtests that just makes sense on certain distros:
> > > test_bitbake_g cannot be done on poky-tiny and test_non_gplv3
> > > just makes sense on poky and poky-tiny. Skip these when
> > > necessary under the latter conditions.
> > >
> > > [YOCTO #8525]
> > >
> > > Signed-off-by: Leonardo Sandoval > > x.in
> > > tel.com>
> > > ---
> > > meta/lib/oeqa/selftest/bbtests.py | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/meta/lib/oeqa/selftest/bbtests.py
> > > b/meta/lib/oeqa/selftest/bbtests.py
> > > index baae1e0..9b11cd9 100644
> > > --- a/meta/lib/oeqa/selftest/bbtests.py
> > > +++ b/meta/lib/oeqa/selftest/bbtests.py
> > > @@ -114,6 +114,9 @@ class BitbakeTests(oeSelfTest):
> > >
> > > @testcase(167)
> > > def test_bitbake_g(self):
> > > +if self.distro == 'poky-tiny':
> > > +self.skipTest('core-image-full-cmdline is not
> > > buildable
> > > with poky-tiny')
> > > +
> > This test is still valid for poky-tiny, it's just that the image
> > the
> > test builds isn't buildable with poky-tiny, right?
> >
> > I think it would be better to change the test to a different,
> > smaller,
> > image that can also be built for poky-tiny (core-image-minimal?).
> > We'd also need to change the target the test checks for the
> > presence of
> > in pn-buildlist.
> Good idea. Which image and pn-buildlist package check do you suggest?
It doesn't really matter and will depend on which image you decide to
build for the test.
The goal of the test appears to be to validate the output of `bitbake
-e`. Hopefully we can find an image and recipe combination which is
buildable across distros but I don't know what that would be off the
top of my head.
Regards,
Joshua
> >
> > Regards,
> >
> > Joshua
> >
> > >
> > > result = bitbake('-g core-image-full-cmdline')
> > > for f in ['pn-buildlist', 'pn-depends.dot', 'package-
> > > depends.dot', 'task-depends.dot']:
> > > self.addCleanup(os.remove, f)
> > > @@ -229,6 +232,10 @@ INHERIT_remove = \"report-error\"
> > >
> > > @testcase(1119)
> > > def test_non_gplv3(self):
> > > +supported_distros = ['poky', 'poky-tiny']
> > > +if not self.distro in supported_distros:
> > > +self.skipTest('Test considers only %s distros' %
> > > ','.join(supported_distros))
> > > +
> > > data = 'INCOMPATIBLE_LICENSE = "GPLv3"'
> > > conf = os.path.join(self.builddir, 'conf/local.conf')
> > > ftools.append_file(conf ,data)
> > > --
> > > 2.1.4
> > >
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 7/9] selftest: skip runtime-test's test_testimage_install on poky-tiny distro
On Mon, 2016-10-17 at 11:02 -0500, Leonardo Sandoval wrote:
>
> On 10/17/2016 02:09 AM, Joshua Lock wrote:
> >
> > On Fri, 2016-10-14 at 11:40 -0500,
> > leonardo.sandoval.gonza...@linux.intel.com wrote:
> > >
> > > From: Leonardo Sandoval > > om>
> > >
> > > Distro poky-tiny cannot build the core-image-full-cmdline image,
> > > so
> > > skip the
> > > test if this is the case.
> > >
> > > [YOCTO #8525]
> > Wouldn't it be better to use a different image, most likely with
> > extra
> > packages installed, and maybe a different list of TEST_SUITES for
> > poky-
> > tiny so that we're still testing this functionality on poky-tiny?
>
> Yes, that is a good idea. Which image and the accompanied tests do
> you
> suggest?
I'd be inclined to suggest core-image-minimal with extra packages
installed to enable the same TEST_SUITES, but I can't recall exactly
what's being tested here. Would that combination make sense?
Thanks,
Joshua
>
> >
> > Thanks,
> >
> > Joshua
> >
> > >
> > > Signed-off-by: Leonardo Sandoval > > x.in
> > > tel.com>
> > > ---
> > > meta/lib/oeqa/selftest/runtime-test.py | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/lib/oeqa/selftest/runtime-test.py
> > > b/meta/lib/oeqa/selftest/runtime-test.py
> > > index c2d5b45..e17c261 100644
> > > --- a/meta/lib/oeqa/selftest/runtime-test.py
> > > +++ b/meta/lib/oeqa/selftest/runtime-test.py
> > > @@ -94,6 +94,8 @@ class TestImage(oeSelfTest):
> > > Product: oe-core
> > > Author: Mariano Lopez
> > > """
> > > +if self.distro == 'poky-tiny':
> > > +self.skipTest('core-image-full-cmdline not buildable
> > > for
> > > poky-tiny')
> > >
> > > features = 'INHERIT += "testimage"\n'
> > > features += 'TEST_SUITES = "ping ssh selftest"\n'
> > > --
> > > 2.1.4
> > >
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-arch.bbclass: Add xtensa and arc into valid_archs table
> On Oct 18, 2016, at 9:13 AM, Bystricky, Juro wrote: > > The single purpose of "map_kernel_arch" is to set > > export ARCH = "arch_xxx" > > Presently, we must set ARCH even when building baremetal toolchains only, > without any need to build kernel. However, in this case we may > encounter a bogus error such as "cannot map arch_xxx to a linux kernel > architecture". > The simplest way to avoid this is to place arch_xxx into the table > "valid_archs". (That was the main reason for the patch). > > A better but more complex way would be to modify the code so > map_kernel_arch is not called at all when NOT building kernel or kernel > modules. This would also allow building baremetal cross-toolchains for arches > that don't have Linux kernels at all. > > Another way to consider is perhaps just getting rid of the table > "valid_archs" entirely. > > "map_kernel_arch" maps arch_aaa -> arch_xxx for some cases. > If there is no explicit mapping, then it could simply map > > arch_aaa->arch_aaa > > resulting in export ARCH="arch_aaa" > There would be no error generated. If ARCH is not a valid > arch for a Linux kernel, we would encounter a build error at some point. > But that, I believe is the same case now if we try to build a kernel > with a valid kernel ARCH but not supported actively in OE or extended OE > ecosystem. I think you should add a check for testing TARGET_OS and if its not linux then ignore the valid kernel arches check. > > > > >> -Original Message- >> From: Khem Raj [mailto:raj.k...@gmail.com] >> Sent: Monday, October 17, 2016 4:40 PM >> To: Bystricky, Juro >> Cc: openembedded-core@lists.openembedded.org; jurobystri...@hotmail.com >> Subject: Re: [OE-core] [PATCH] kernel-arch.bbclass: Add xtensa and arc into >> valid_archs table >> >> >>> On Oct 11, 2016, at 9:31 AM, Juro Bystricky >> wrote: >>> >>> Both "arc" and "xtensa" are valid Linux architectures, add >>> them into valid_archs table. >>> >>> Signed-off-by: Juro Bystricky >>> --- >>> meta/classes/kernel-arch.bbclass | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel- >> arch.bbclass >>> index 8a4bef1..ea976c6 100644 >>> --- a/meta/classes/kernel-arch.bbclass >>> +++ b/meta/classes/kernel-arch.bbclass >>> @@ -14,7 +14,7 @@ valid_archs = "alpha cris ia64 \ >>> parisc s390 v850 \ >>> avr32 blackfin \ >>> microblaze \ >>> - nios2" >>> + nios2 arc xtensa” >> >> there parisc etc as well so in essence patch is ok but I wonder if we >> should >> remove the arches we dont actively support in OE or extended OE ecosystem. >> >>> >>> def map_kernel_arch(a, d): >>>import re >>> -- >>> 2.7.4 >>> >>> -- >>> ___ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Minutes from OEDEM on 10/14
Many thanks to the people that helped take minutes at OEDEM. Jefro copied them fro the google doc to the wiki. http://openembedded.org/wiki/OEDEM_2016#Minutes Philip PS: Please trim replies to this email to an appropriate list. -ETOOMANYLISTS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Re-add piglit to sdk images
On Tue, 18 Oct 2016 11:13:11 Randy MacLeod wrote: > On 2016-10-14 02:31 PM, Jussi Kukkonen wrote: > > Piglit was removed because the current version was making sdk > > images too large. This patchset reduces the installed size by 1.5GB > > and adds piglit back to core-tools-testapps. > > > > Running piglit still requires the same amount of space so in practice > > this is useful for installed images only. > > > > Q: Do I need to declare a runtime dependency that typically comes > > from busybox (tar)? > > Yes, because some people try to eliminate busybox from their image. How would one express such a dependency though, given that it could come from tar or busybox? "Virtual" runtime dependencies aren't allowed except through our somewhat awkward VIRTUAL-RUNTIME convention, but that probably isn't warranted here. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] insane.bbclass: Additional "mips" and "mipsel" machine definitions
On Tue, 18 Oct 2016 09:23:12 Juro Bystricky wrote: > Add "mips" and "mipsel" to "machdata" table. > Although there is a way to add entries to the "machdata" table > from a BSP without modifying the insane.bbclass directly, MIPS is > already supported in openembedded-core and as such the relevant entries > should be present in insane.bbclass. It seems v1 was already merged I'm afraid. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] u-boot: Drop the +git part from PV
The U-Boot package is using release versions of U-Boot,
so drop the extra +git part from PV.
Signed-off-by: Marek Vasut
Cc: Richard Purdie
Cc: Denys Dmytriyenko
---
meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
index ead5077..0a90621 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
# repo during parse
SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
-PV = "v2016.09.01+git${SRCPV}"
+PV = "v2016.09.01"
SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
--
2.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] u-boot: Factor out common bits
The u-boot recipes share a couple of common variables, which makes
updating of the recipes error prone and a toil. Factor those common
bits into u-boot-common_${PV}.inc so that they are in one place.
The u-boot_${PV}.bb now explicitly require u-boot-common_${PV}.inc
before require u-boot.inc , as doing require u-boot-common_${PV}.inc
from u-boot.inc would fail due to ${PV} not being set. This is a
functional change.
Signed-off-by: Marek Vasut
Cc: Richard Purdie
Cc: Denys Dmytriyenko
---
meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc | 16
meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb | 16 ++--
meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb | 17 ++---
meta/recipes-bsp/u-boot/u-boot.inc | 8
meta/recipes-bsp/u-boot/u-boot_2016.03.bb | 8 +---
5 files changed, 21 insertions(+), 44 deletions(-)
create mode 100644 meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
b/meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
new file mode 100644
index 000..403e316
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
@@ -0,0 +1,16 @@
+HOMEPAGE = "http://www.denx.de/wiki/U-Boot/WebHome";
+SECTION = "bootloaders"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
+
+# This revision corresponds to the tag "v2016.03"
+# We use the revision in order to avoid having to fetch it from the
+# repo during parse
+SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa"
+
+PV = "v2016.03+git${SRCPV}"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+
+S = "${WORKDIR}/git"
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
index 79f1548..f56862c 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
@@ -1,20 +1,8 @@
+require u-boot-common_${PV}.inc
+
SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
-SECTION = "bootloader"
DEPENDS = "mtd-utils"
-# This revision corresponds to the tag "v2016.03"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa"
-
-PV = "v2016.03+git${SRCPV}"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
-
-S = "${WORKDIR}/git"
-
INSANE_SKIP_${PN} = "already-stripped"
EXTRA_OEMAKE_class-target = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${CC}
${CFLAGS} ${LDFLAGS}" V=1'
EXTRA_OEMAKE_class-cross = 'ARCH=${TARGET_ARCH} CC="${CC} ${CFLAGS}
${LDFLAGS}" V=1'
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
index d5921a0..5025961 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
@@ -1,21 +1,8 @@
-SUMMARY = "U-Boot bootloader image creation tool"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
-SECTION = "bootloader"
+require u-boot-common_${PV}.inc
+SUMMARY = "U-Boot bootloader image creation tool"
DEPENDS = "openssl"
-# This revision corresponds to the tag "v2016.03"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa"
-
-PV = "v2016.03+git${SRCPV}"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
-
-S = "${WORKDIR}/git"
-
EXTRA_OEMAKE = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS}
${LDFLAGS}" STRIP=true V=1'
do_compile () {
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index 252aae9..afe3fe9 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -1,14 +1,6 @@
SUMMARY = "Universal Boot Loader for embedded devices"
-HOMEPAGE = "http://www.denx.de/wiki/U-Boot/WebHome";
-SECTION = "bootloaders"
PROVIDES = "virtual/bootloader"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
-
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
-
-S = "${WORKDIR}/git"
B = "${WORKDIR}/build"
PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot_2016.03.bb
index 836b0ce..dabe709 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2016.03.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2016.03.bb
@@ -1,10 +1,4 @@
+require u-boot-common_${PV}.inc
require u-boot.inc
DEPENDS += "dtc-native"
-
-# This revision corresponds to the tag "v2016.03"
-# We use the revision in order to avoid having to fetch it from the
-# repo during parse
-SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa"
-
-PV = "v2016.03+git${SRCPV}"
--
2.9.3
--
___
[OE-core] [PATCH 2/5] u-boot: Update to 2016.09.01 release
Upgrade U-Boot to the latest version.
Signed-off-by: Marek Vasut
Cc: Richard Purdie
Cc: Denys Dmytriyenko
---
.../{u-boot-common_2016.03.inc => u-boot-common_2016.09.01.inc} | 8
.../{u-boot-fw-utils_2016.03.bb => u-boot-fw-utils_2016.09.01.bb} | 0
.../{u-boot-mkimage_2016.03.bb => u-boot-mkimage_2016.09.01.bb} | 0
.../u-boot/{u-boot_2016.03.bb => u-boot_2016.09.01.bb}| 0
4 files changed, 4 insertions(+), 4 deletions(-)
rename meta/recipes-bsp/u-boot/{u-boot-common_2016.03.inc =>
u-boot-common_2016.09.01.inc} (59%)
rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.03.bb =>
u-boot-fw-utils_2016.09.01.bb} (100%)
rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.03.bb =>
u-boot-mkimage_2016.09.01.bb} (100%)
rename meta/recipes-bsp/u-boot/{u-boot_2016.03.bb => u-boot_2016.09.01.bb}
(100%)
diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
similarity index 59%
rename from meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
rename to meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
index 403e316..ead5077 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2016.03.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
@@ -4,13 +4,13 @@ SECTION = "bootloaders"
LICENSE = "GPLv2+"
LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
-# This revision corresponds to the tag "v2016.03"
+# This revision corresponds to the tag "v2016.09.01"
# We use the revision in order to avoid having to fetch it from the
# repo during parse
-SRCREV = "df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa"
+SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
-PV = "v2016.03+git${SRCPV}"
+PV = "v2016.09.01+git${SRCPV}"
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.03.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.03.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.03.bb
b/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2016.03.bb
rename to meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
--
2.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] u-boot: Drop PV altogether
Drop the explicit setting of PV altogether. This changes the U-Boot
version string from "v20yy.mm" to "20yy.mm" , so layer setting the
PREFERRED_VERSION_u-boot must be updated by removing the leading 'v'.
Signed-off-by: Marek Vasut
Cc: Richard Purdie
Cc: Denys Dmytriyenko
---
meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
index 0a90621..a535df1 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
@@ -9,8 +9,6 @@ LIC_FILES_CHKSUM =
"file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
# repo during parse
SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
-PV = "v2016.09.01"
-
SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
S = "${WORKDIR}/git"
--
2.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] u-boot: Drop redundant comment
Drop comment stating that the SRCREV corresponds to particular U-Boot version. This comment is redundant, since the U-Boot version is part of the recipe filename. Signed-off-by: Marek Vasut Cc: Richard Purdie Cc: Denys Dmytriyenko --- meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc index a535df1..5b02c87 100644 --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc @@ -4,7 +4,6 @@ SECTION = "bootloaders" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6" -# This revision corresponds to the tag "v2016.09.01" # We use the revision in order to avoid having to fetch it from the # repo during parse SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9" -- 2.9.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [krogoth][PATCH 00/10] Backports from master (cover letter only)
These have passed through the devtool/recipetool/bblayers oe-selftest tests. The following changes since commit a8f44dff13481feaa97e494a3aeafb5b63d40f3f: binutils: fix AR issue when opkg is unpacking IPKs containing empty entries (2016-10-06 14:09:32 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/krogoth-fixes-oe http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/krogoth-fixes-oe Ola x Nilsson (2): devtool: build_image: Fix recipe filter devtool: Use the wildcard flag in update_recipe_patch Paul Eggleton (8): devtool: update-recipe: fix --initial-rev option devtool: reset: allow reset to work if the recipe file has been deleted recipetool: create: fix handling of github URLs lib/oe/recipeutils: fix patch_recipe*() with empty input recipetool: create: fix greedy regex that broke support for github tarballs oe-selftest: recipetool: add tests for git URL mangling devtool: add: fix error message when only specifying a recipe name classes/externalsrc: re-run do_configure when configure files change meta/classes/autotools.bbclass | 2 ++ meta/classes/cmake.bbclass | 2 ++ meta/classes/externalsrc.bbclass | 22 ++ meta/lib/oe/recipeutils.py | 2 +- meta/lib/oeqa/selftest/recipetool.py | 43 scripts/lib/devtool/build_image.py | 2 +- scripts/lib/devtool/standard.py | 18 +++ scripts/lib/recipetool/create.py | 2 +- 8 files changed, 80 insertions(+), 13 deletions(-) -- 2.5.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [krogoth][PATCH 00/10] Backports from master (cover letter only)
On 10/18/2016 03:15 PM, Paul Eggleton wrote: These have passed through the devtool/recipetool/bblayers oe-selftest tests. The following changes since commit a8f44dff13481feaa97e494a3aeafb5b63d40f3f: binutils: fix AR issue when opkg is unpacking IPKs containing empty entries (2016-10-06 14:09:32 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/krogoth-fixes-oe http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/krogoth-fixes-oe In my staging. Thanks, Armin Ola x Nilsson (2): devtool: build_image: Fix recipe filter devtool: Use the wildcard flag in update_recipe_patch Paul Eggleton (8): devtool: update-recipe: fix --initial-rev option devtool: reset: allow reset to work if the recipe file has been deleted recipetool: create: fix handling of github URLs lib/oe/recipeutils: fix patch_recipe*() with empty input recipetool: create: fix greedy regex that broke support for github tarballs oe-selftest: recipetool: add tests for git URL mangling devtool: add: fix error message when only specifying a recipe name classes/externalsrc: re-run do_configure when configure files change meta/classes/autotools.bbclass | 2 ++ meta/classes/cmake.bbclass | 2 ++ meta/classes/externalsrc.bbclass | 22 ++ meta/lib/oe/recipeutils.py | 2 +- meta/lib/oeqa/selftest/recipetool.py | 43 scripts/lib/devtool/build_image.py | 2 +- scripts/lib/devtool/standard.py | 18 +++ scripts/lib/recipetool/create.py | 2 +- 8 files changed, 80 insertions(+), 13 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] kernel-yocto: (small) consolidated pull request
Hi all, Here are two patches that I've been carrying that are safe for the 2.2 release. I have other patches/fixes and -stable updates in my queue, but I'm going to hold them back until after the release in the name of stability. We have one configuration cleanup patch, and a kern tools change to allow patches with things like () ;, etc in their names (I ran into this when refreshing the preempt-rt series today and it has patches with () in their name. Cheers, Bruce The following changes since commit 4b94b498e21aeba945fe7e72a6b7c4bb0314fb83: bitbake: toaster: Update default release to Morty (2016-10-15 13:21:54 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (2): linux-yocto/4.4/4.8: kernel config warning cleanups kern-tools: make patches with shell-unsafe characters valid meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb| 2 +- meta/recipes-kernel/linux/linux-yocto_4.8.bb| 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) -- 2.5.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] linux-yocto/4.4/4.8: kernel config warning cleanups
Merging the following patches into 4.4 and 4.8 to remove kernel
configuration warnings:
bbaf01752b01 meta-yocto-bsp: beaglebone: remove the stale kernel options
552a83790b17 features: Fix configcheck warnings in features used by
intel-quark BSPs
c33d9c2c575f features: Fix configcheck warnings in features used by
intel-core* BSPs
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_4.8.bb | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index 4fc3458b5fae..33091f1b4ff6 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -12,7 +12,7 @@ python () {
}
SRCREV_machine ?= "6f27f97ed8466b5d7390e8fbb8696c13835a0b1f"
-SRCREV_meta ?= "d9f20333c42e024d42d633b3da2458f2e0d9c52a"
+SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index 565d8997fa54..fc1c40caf7b2 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -12,7 +12,7 @@ python () {
}
SRCREV_machine ?= "b266f7ba78f0cb3d7073e1bf7bd7dfc92bec7431"
-SRCREV_meta ?= "03bf3dd73190db9c615565d37c02f218382a2283"
+SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index 7ca5d86dcd42..44ddf21c04b8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
SRCREV_machine ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_meta ?= "d9f20333c42e024d42d633b3da2458f2e0d9c52a"
+SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index b669efedd5dc..41ff5637ec59 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_meta ?= "03bf3dd73190db9c615565d37c02f218382a2283"
+SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index f2d07be2dc89..41db3f682ae6 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"f4e52341c304e044dbe581a35aad6b930c9410d1"
SRCREV_machine_qemux86-64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
SRCREV_machine_qemumips64 ?= "857685d23d1e8d8a8deb4198b139b95a5bb80825"
SRCREV_machine ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_meta ?= "d9f20333c42e024d42d633b3da2458f2e0d9c52a"
+SRCREV_meta ?= "bbaf01752b0168a63b164978495fad4ead7e8972"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH};
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index bc4941bb22b2..5738f4974b9b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"67813e7efa3a4614e209c2f058d92ef9a636441a"
SRCREV_machine_qemux86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
SRCREV_machine_qemumips64 ?= "674818dad577cdfc23c6c857aa2b769fc64e379c"
SRCREV_machine ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_meta ?= "03bf3dd73190db9c615565d37c02f218382a2283"
+SRCREV_meta ?= "552a83790b1797b6dd4e4c48ff5bc8f215ed57da"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH};
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto
[OE-core] [PATCH 2/2] kern-tools: make patches with shell-unsafe characters valid
If a patch contains characters like ; or (), it can cause processing
errors in the patch queue.
We had previously fixed this issue by renaming the patches to not
include invalid characters, but with this change to the kern tools
that ensures patch names are wrapped in quotes, we avoid shell
processing and hence they are valid.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 6877a0cf18c4..d8041ddd38c5 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
DEPENDS = "git-native"
-SRCREV = "4b5de9011b31ff92ba2b6e052ab818b09affd905"
+SRCREV = "9a3995ee8daabf37e92e1b51b133cf8582d85809"
PR = "r12"
PV = "0.2+git${SRCPV}"
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] buildstats: check IMAGE_ROOTFS exists before checking its size
After 0d6b7276003f1afabc6de683f663540327d52bdc, the exceptions are
correctly checked if the rootfs size check fails. In case of a
failure a build error is triggered.
However, there are cases where this is known to fail (e.g.,
with meta-swupd the rootfs for swupd images is other than IMAGE_ROOTFS).
Because of that, check IMAGE_ROOTFS exists before trying to get the
size of it. Also, in case of any error catched as err, simply print
out a warning.
Signed-off-by: Mikko Ylinen
---
meta/classes/buildstats.bbclass | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/classes/buildstats.bbclass b/meta/classes/buildstats.bbclass
index 8c2b7b3..599a219 100644
--- a/meta/classes/buildstats.bbclass
+++ b/meta/classes/buildstats.bbclass
@@ -163,12 +163,13 @@ python run_buildstats () {
bs = os.path.join(bsdir, "build_stats")
with open(bs, "a") as f:
rootfs = d.getVar('IMAGE_ROOTFS', True)
-try:
-rootfs_size = subprocess.check_output(["du", "-sh",
rootfs],
-stderr=subprocess.STDOUT).decode('utf-8')
-except subprocess.CalledProcessError as e:
-bb.error("Failed to get rootfs size: %s" % e.output)
-f.write("Uncompressed Rootfs size: %s" % rootfs_size)
+if os.path.isdir(rootfs):
+try:
+rootfs_size = subprocess.check_output(["du", "-sh",
rootfs],
+stderr=subprocess.STDOUT).decode('utf-8')
+f.write("Uncompressed Rootfs size: %s" % rootfs_size)
+except subprocess.CalledProcessError as err:
+bb.warn("Failed to get rootfs size: %s" %
err.output.decode('utf-8'))
elif isinstance(e, bb.build.TaskFailed):
# Can have a failure before TaskStarted so need to mkdir here too
--
2.9.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
