* Re: Contents of non-rootfs partitions
From: Enrico Joerns @ 2016-11-23 10:12 UTC (permalink / raw)
To: Maciej Borzęcki
Cc: Eduard Bartosh, Patches and discussions about the oe-core layer
In-Reply-To: <CAD4b0_LrF=sQMV3r+3Kb8hqxcqD9U_LBMesxCyby+FGS7YssFQ@mail.gmail.com>
On 11/23/2016 10:24 AM, Maciej Borzęcki wrote:
> On Wed, Nov 23, 2016 at 9:40 AM, Enrico Joerns <ejo@pengutronix.de> wrote:
>> On 11/22/2016 12:54 PM, Kristian Amlie wrote:
>>>
>>> On 22/11/16 12:10, Patrick Ohly wrote:
>>>>>
>>>>> ...
>>>>
>>>>
>>>> All of these introduce some special mechanism. Let me propose something
>>>> that might integrate better with the existing tooling:
>>>>
>>>> The "rootfs" directory gets redefined as representing the entire virtual
>>>> file system. When creating a disk image, it gets split up into different
>>>> partitions based on the image configuration.
>>>>
>>>> For example, the /home or /data directories in the rootfs could hold the
>>>> content that in some image configurations goes into separate partitions.
>>>>
>>>> The advantage of this approach is that the tooling for staging content
>>>> for image creation does not need to be changed. The same staged content
>>>> then can be used to create different images, potentially even using
>>>> different partition layouts.
>>>
>>>
>>> That's a very good idea. I think it beats all of my suggestions!
>>
>>
>> I totally agree with this solution, because it is the same approach we are
>> already using for several years.
>>
>> Instead of wic we are using the genimage tool
>> (http://public.pengutronix.de/software/genimage/) together with a Yocto
>> class for easing image creation, but its pretty much the same concerning its
>> base purpose.
>>
>> We called the option to split up 'mountpoint' while assuming that the
>> splitted partition will be mounted to the same location in the file system
>> it was taken from.
>>
>> An example configuration would look like this (stripped down to the
>> essential parts):
>>
>> image my-disk-image {
>> [...]
>> partition root {
>> image = "rootfs.ext4"
>> [...]
>> }
>>
>> partition home {
>> image = "home.ext4"
>> [...]
>> }
>> }
>>
>> image rootfs.ext4 {
>> [...]
>> mountpoint = "/"
>> }
>>
>> image home.ext4 {
>> [...]
>> mountpoint = "/home"
>> }
>>
>> Maybe a similar approach could be used in wic, too.
>
> I went through the README from genimage repo
> https://git.pengutronix.de/cgit/genimage/tree/README. Definitely looks
> interesting and covers storage medias that are not supported by wic
> right now. The split option does not seem to be documented though. If I
> understood you correctly, the partition is seeded with data from
> location specified by `mountpoint` inside IMAGE_ROOTFS. Is that correct?
Yes, what the genimage class (see below) does, is unpacking the final
rootfs.tar.xz inside a fakeroot environment and call the genimage tool
with the --rootpath argument set to this path.
The mountpoint="/home" tells genimage to pack all content in directory
/home into a separate data ext4 image (temporary named 'home.ext4') and
all other content in a rootfs ext4 image (temporary named 'rootfs.ext4').
The `image` section then specifies how to construct the final disk image
using the referenced generated rootfs and datafs images (and optionally
some bootloader, non-partition-data, etc.).
Note that this is only one way to use genimage. Another common way to
use it is to simply construct complex disk images out of different
filesystem images, e.g. with
partition barebox {
image = "barebox-any-platform.img"
size = 1M
in-partition-table = false
}
> I see there's a large overlap in functionality with wic (at least for
> block devices), so perhaps the best way would be introduce genimage as
> another IMAGE_CMD.
>
> I've quickly checked at https://layers.openembedded.org and there are no
> recipes for genimage/libconfuse listed there. Do happen to have done
> integration with OE in some private repo already? Would it be possible
> for you to post the relevant patches?
>
We have a layer for this, which is potentially publicly available but
not advertised as the general plan was to move some of its content to
upstream (oe-core, meta-oe) and split up other content (e.g. the rauc
update tool stuff) to separate layers that will be made publicly
available. But, as always, there are more plans than time left ;)
Well, to make a long story short, the path to the git repository is:
https://git.pengutronix.de/cgit/meta-ptx
The genimage class I mentioned above you can find in it, too:
https://git.pengutronix.de/cgit/meta-ptx/tree/classes/genimage.bbclass
When starting with Yocto I thought about changing from genimage to wic
for disk image creation as wic already seemed to become the standard
solution for building disk images. But back in these days it was a very
separate tool and there was no integration with the BSP itself (which is
crucial when having to reproduce builds). But the main reason why I
decided to stay with genimage was that wic simply did not cover most of
the use cases I required for building complex disk images for different
embedded platforms. I'm pretty sure that this has changed in some
points, but had no time to get deeper into this topic again, yet.
Hope that helps, best regards
Enrico
--
Pengutronix e.K. | Enrico Jörns |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* migrating simple tarballs over to OE recipes?
From: Robert P. J. Day @ 2016-11-23 10:42 UTC (permalink / raw)
To: OE Core mailing list
colleague has a pile of tarballs that were used to customize an x86
centos system, wants to move all that to OE with as little fuss as
possible, i guess the simplest way is to just create recipes that have
the same tarball in the files/ directory, and write a trivial
do_install() task that untars it into the root fs, yes?
hacky, but it should work. is there a cleaner solution that i'm just
stupidly overlooking?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Maciej Borzęcki @ 2016-11-23 11:03 UTC (permalink / raw)
To: Enrico Joerns
Cc: Eduard Bartosh, Patches and discussions about the oe-core layer
In-Reply-To: <71ba6b2a-4a87-9544-d249-c3fccc48a9f5@pengutronix.de>
On Wed, Nov 23, 2016 at 11:12 AM, Enrico Joerns <ejo@pengutronix.de> wrote:
> On 11/23/2016 10:24 AM, Maciej Borzęcki wrote:
>>
<snip>
>
> Yes, what the genimage class (see below) does, is unpacking the final
> rootfs.tar.xz inside a fakeroot environment and call the genimage tool with
> the --rootpath argument set to this path.
>
> The mountpoint="/home" tells genimage to pack all content in directory /home
> into a separate data ext4 image (temporary named 'home.ext4') and all other
> content in a rootfs ext4 image (temporary named 'rootfs.ext4').
>
> The `image` section then specifies how to construct the final disk image
> using the referenced generated rootfs and datafs images (and optionally some
> bootloader, non-partition-data, etc.).
>
>
> Note that this is only one way to use genimage. Another common way to use it
> is to simply construct complex disk images out of different filesystem
> images, e.g. with
>
> partition barebox {
> image = "barebox-any-platform.img"
> size = 1M
> in-partition-table = false
> }
>
>> I see there's a large overlap in functionality with wic (at least for
>> block devices), so perhaps the best way would be introduce genimage as
>> another IMAGE_CMD.
>>
>> I've quickly checked at https://layers.openembedded.org and there are no
>> recipes for genimage/libconfuse listed there. Do happen to have done
>> integration with OE in some private repo already? Would it be possible
>> for you to post the relevant patches?
>>
>
> We have a layer for this, which is potentially publicly available but not
> advertised as the general plan was to move some of its content to upstream
> (oe-core, meta-oe) and split up other content (e.g. the rauc update tool
> stuff) to separate layers that will be made publicly available. But, as
> always, there are more plans than time left ;)
>
> Well, to make a long story short, the path to the git repository is:
>
> https://git.pengutronix.de/cgit/meta-ptx
>
> The genimage class I mentioned above you can find in it, too:
>
> https://git.pengutronix.de/cgit/meta-ptx/tree/classes/genimage.bbclass
>
>
> When starting with Yocto I thought about changing from genimage to wic for
> disk image creation as wic already seemed to become the standard solution
> for building disk images. But back in these days it was a very separate tool
> and there was no integration with the BSP itself (which is crucial when
> having to reproduce builds). But the main reason why I decided to stay with
> genimage was that wic simply did not cover most of the use cases I required
> for building complex disk images for different embedded platforms. I'm
> pretty sure that this has changed in some points, but had no time to get
> deeper into this topic again, yet.
>
>
> Hope that helps, best regards
Thanks a lot. Very helpful indeed.
--
Maciej Borzecki
RnDity
^ permalink raw reply
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Patrick Ohly @ 2016-11-23 11:16 UTC (permalink / raw)
To: Robert Yang; +Cc: openembedded-core
In-Reply-To: <e1b37a8090d9fe6d93d6f68301d5c89a45a93b37.1479871728.git.liezhi.yang@windriver.com>
On Tue, 2016-11-22 at 23:49 -0800, Robert Yang wrote:
> [YOCTO #10710]
>
> Otherwise, we can't login as root when debug-tweaks is not in
> IMAGE_FEATURES, and there is no other users to login by default, so
> there is no way to login.
Wait a second, are you really suggesting that OE-core should have a
default root password in its default configuration?
That's very bad practice and I'm against doing it this way. Having a
default password is one of the common vulnerabilities in actual devices
on the market today. OE-core should make it hard to make that mistake,
not actively introduce it.
So if you think that having a root password set (instead of empty), then
at least make it an opt-in behavior that explicitly has to be selected.
Make it an image feature so that images with and without default
password can be build in the same build configuration. Changing
base-passwd doesn't achieve that.
Even then I'm still wondering what the benefit of a well-known password
compared to no password is. Both are equally insecure, so someone who
wants to allow logins might as well go with "empty password".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: migrating simple tarballs over to OE recipes?
From: Burton, Ross @ 2016-11-23 11:21 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611230540200.7856@ca624034.mitel.com>
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
On 23 November 2016 at 10:42, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
> colleague has a pile of tarballs that were used to customize an x86
> centos system, wants to move all that to OE with as little fuss as
> possible, i guess the simplest way is to just create recipes that have
> the same tarball in the files/ directory, and write a trivial
> do_install() task that untars it into the root fs, yes?
>
Pretty much, yeah.
If you've a large pile and they're all effectively the same then a little
class can automate it even more.
Ross
[-- Attachment #2: Type: text/html, Size: 1052 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/7] wic: selftest: do not repeat core-image-minimal
From: Ed Bartosh @ 2016-11-23 11:23 UTC (permalink / raw)
To: Maciej Borzecki; +Cc: Paul Eggleton, Maciej Borzecki, openembedded-core
In-Reply-To: <fd75ccfd4bbd3420f72b32c815feb92b06b2b9fb.1479887010.git.maciej.borzecki@rndity.com>
On Wed, Nov 23, 2016 at 08:46:31AM +0100, Maciej Borzecki wrote:
> Replace repeated core-image-minimal with Wic class field.
>
> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
> ---
> meta/lib/oeqa/selftest/wic.py | 111 +++++++++++++++++++++++++++---------------
> 1 file changed, 73 insertions(+), 38 deletions(-)
>
> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
> index 2db14445956bc5adcf1e755844bbdb69edcb468f..37ed2c6de5a7f22f982f921476fa392304995b2e 100644
> --- a/meta/lib/oeqa/selftest/wic.py
> +++ b/meta/lib/oeqa/selftest/wic.py
> @@ -57,6 +57,8 @@ class Wic(oeSelfTest):
> resultdir = "/var/tmp/wic/build/"
> image_is_ready = False
>
> + OE_IMAGE = "core-image-minimal"
> +
> def setUpLocal(self):
> """This code is executed before each test method."""
> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
> @@ -75,7 +77,7 @@ class Wic(oeSelfTest):
> tools += ' syslinux syslinux-native'
> bitbake(tools)
>
> - bitbake('core-image-minimal')
> + bitbake(self.OE_IMAGE)
> Wic.image_is_ready = True
I'd agree with Ross here - it looks less readable.
How it would look if we decide to add test case for another image?
>
> rmtree(self.resultdir, ignore_errors=True)
> @@ -100,14 +102,14 @@ class Wic(oeSelfTest):
> def test_build_image_name(self):
> """Test wic create directdisk --image-name core-image-minimal"""
> self.assertEqual(0, runCmd("wic create directdisk "
> - "--image-name core-image-minimal").status)
> + "--image-name %s" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + "directdisk-*.direct")))
>
> @testcase(1212)
> @onlyForArch('i586', 'i686', 'x86_64')
> def test_build_artifacts(self):
> """Test wic create directdisk providing all artifacts."""
> - bbvars = dict((var.lower(), get_bb_var(var, 'core-image-minimal')) \
> + bbvars = dict((var.lower(), get_bb_var(var, self.OE_IMAGE)) \
> for var in ('STAGING_DATADIR', 'DEPLOY_DIR_IMAGE',
> 'STAGING_DIR_NATIVE', 'IMAGE_ROOTFS'))
> status = runCmd("wic create directdisk "
> @@ -123,7 +125,7 @@ class Wic(oeSelfTest):
> def test_gpt_image(self):
> """Test creation of core-image-minimal with gpt table and UUID boot"""
> self.assertEqual(0, runCmd("wic create directdisk-gpt "
> - "--image-name core-image-minimal").status)
> + "--image-name %s" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + "directdisk-*.direct")))
>
> @testcase(1213)
> @@ -157,8 +159,8 @@ class Wic(oeSelfTest):
> def test_compress_gzip(self):
> """Test compressing an image with gzip"""
> self.assertEqual(0, runCmd("wic create directdisk "
> - "--image-name core-image-minimal "
> - "-c gzip").status)
> + "--image-name %s "
> + "-c gzip" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + \
> "directdisk-*.direct.gz")))
>
> @@ -167,8 +169,8 @@ class Wic(oeSelfTest):
> def test_compress_bzip2(self):
> """Test compressing an image with bzip2"""
> self.assertEqual(0, runCmd("wic create directdisk "
> - "--image-name core-image-minimal "
> - "-c bzip2").status)
> + "--image-name %s "
> + "-c bzip2" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + \
> "directdisk-*.direct.bz2")))
>
> @@ -177,8 +179,8 @@ class Wic(oeSelfTest):
> def test_compress_xz(self):
> """Test compressing an image with xz"""
> self.assertEqual(0, runCmd("wic create directdisk "
> - "--image-name core-image-minimal "
> - "-c xz").status)
> + "--image-name %s "
> + "-c xz" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + \
> "directdisk-*.direct.xz")))
>
> @@ -187,26 +189,31 @@ class Wic(oeSelfTest):
> def test_wrong_compressor(self):
> """Test how wic breaks if wrong compressor is provided"""
> self.assertEqual(2, runCmd("wic create directdisk "
> - "--image-name core-image-minimal "
> - "-c wrong", ignore_status=True).status)
> + "--image-name %s "
> + "-c wrong" % self.OE_IMAGE,
> + ignore_status=True).status)
>
> @testcase(1268)
> @onlyForArch('i586', 'i686', 'x86_64')
> def test_rootfs_indirect_recipes(self):
> """Test usage of rootfs plugin with rootfs recipes"""
> wks = "directdisk-multi-rootfs"
> - self.assertEqual(0, runCmd("wic create %s "
> - "--image-name core-image-minimal "
> - "--rootfs rootfs1=core-image-minimal "
> - "--rootfs rootfs2=core-image-minimal" \
> - % wks).status)
> + wic_cmd_vars = {
> + 'wks': wks,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s "
> + "--image-name %(image)s "
> + "--rootfs rootfs1=%(image)s "
> + "--rootfs rootfs2=%(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s*.direct" % wks)))
>
> @testcase(1269)
> @onlyForArch('i586', 'i686', 'x86_64')
> def test_rootfs_artifacts(self):
> """Test usage of rootfs plugin with rootfs paths"""
> - bbvars = dict((var.lower(), get_bb_var(var, 'core-image-minimal')) \
> + bbvars = dict((var.lower(), get_bb_var(var, self.OE_IMAGE)) \
> for var in ('STAGING_DATADIR', 'DEPLOY_DIR_IMAGE',
> 'STAGING_DIR_NATIVE', 'IMAGE_ROOTFS'))
> bbvars['wks'] = "directdisk-multi-rootfs"
> @@ -226,24 +233,23 @@ class Wic(oeSelfTest):
> def test_iso_image(self):
> """Test creation of hybrid iso image with legacy and EFI boot"""
> self.assertEqual(0, runCmd("wic create mkhybridiso "
> - "--image-name core-image-minimal").status)
> + "--image-name %s" % self.OE_IMAGE).status)
> self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-*.direct")))
> self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-*.iso")))
>
> @testcase(1347)
> def test_image_env(self):
> """Test generation of <image>.env files."""
> - image = 'core-image-minimal'
> - self.assertEqual(0, bitbake('%s -c do_rootfs_wicenv' % image).status)
> - stdir = get_bb_var('STAGING_DIR_TARGET', image)
> + self.assertEqual(0, bitbake('%s -c do_rootfs_wicenv' % self.OE_IMAGE).status)
> + stdir = get_bb_var('STAGING_DIR_TARGET', self.OE_IMAGE)
> imgdatadir = os.path.join(stdir, 'imgdata')
>
> - basename = get_bb_var('IMAGE_BASENAME', image)
> - self.assertEqual(basename, image)
> + basename = get_bb_var('IMAGE_BASENAME', self.OE_IMAGE)
> + self.assertEqual(basename, self.OE_IMAGE)
> path = os.path.join(imgdatadir, basename) + '.env'
> self.assertTrue(os.path.isfile(path))
>
> - wicvars = set(get_bb_var('WICVARS', image).split())
> + wicvars = set(get_bb_var('WICVARS', self.OE_IMAGE).split())
> # filter out optional variables
> wicvars = wicvars.difference(('HDDDIR', 'IMAGE_BOOT_FILES',
> 'INITRD', 'ISODIR'))
> @@ -275,8 +281,12 @@ class Wic(oeSelfTest):
> def test_qemux86_directdisk(self):
> """Test creation of qemux-86-directdisk image"""
> image = "qemux86-directdisk"
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>
> @testcase(1349)
> @@ -284,8 +294,12 @@ class Wic(oeSelfTest):
> def test_mkgummidisk(self):
> """Test creation of mkgummidisk image"""
> image = "mkgummidisk"
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>
> @testcase(1350)
> @@ -293,8 +307,12 @@ class Wic(oeSelfTest):
> def test_mkefidisk(self):
> """Test creation of mkefidisk image"""
> image = "mkefidisk"
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>
> @testcase(1385)
> @@ -302,8 +320,12 @@ class Wic(oeSelfTest):
> def test_directdisk_bootloader_config(self):
> """Test creation of directdisk-bootloader-config image"""
> image = "directdisk-bootloader-config"
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>
> @testcase(1422)
> @@ -322,7 +344,12 @@ class Wic(oeSelfTest):
> def test_bmap(self):
> """Test generation of .bmap file"""
> image = "directdisk"
> - status = runCmd("wic create %s -e core-image-minimal --bmap" % image).status
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + status = runCmd("wic create %(wks)s -e %(image)s --bmap" \
> + % wic_cmd_vars).status
> self.assertEqual(0, status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct.bmap" % image)))
> @@ -331,14 +358,22 @@ class Wic(oeSelfTest):
> def test_systemd_bootdisk(self):
> """Test creation of systemd-bootdisk image"""
> image = "systemd-bootdisk"
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>
> def test_sdimage_bootpart(self):
> """Test creation of sdimage-bootpart image"""
> image = "sdimage-bootpart"
> self.write_config('IMAGE_BOOT_FILES = "bzImage"\n')
> - self.assertEqual(0, runCmd("wic create %s -e core-image-minimal" \
> - % image).status)
> + wic_cmd_vars = {
> + 'wks': image,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
> --
> 2.5.0
>
--
--
Regards,
Ed
^ permalink raw reply
* Re: migrating simple tarballs over to OE recipes?
From: Robert P. J. Day @ 2016-11-23 11:34 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE Core mailing list
In-Reply-To: <CAJTo0LZvk-Ssv3Bc5rSYSuYCm2rQma4Vwv2jvh5zdE7cCPE0Vg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
On Wed, 23 Nov 2016, Burton, Ross wrote:
>
> On 23 November 2016 at 10:42, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> colleague has a pile of tarballs that were used to customize an x86
> centos system, wants to move all that to OE with as little fuss as
> possible, i guess the simplest way is to just create recipes that have
> the same tarball in the files/ directory, and write a trivial
> do_install() task that untars it into the root fs, yes?
>
>
> Pretty much, yeah.
>
> If you've a large pile and they're all effectively the same then a
> little class can automate it even more.
already going down that road, just wanted to make sure i hadn't
overlooked something obvious.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH v4 7/7] wic: selftest: add tests for --fixed-size partition flags
From: Ed Bartosh @ 2016-11-23 11:36 UTC (permalink / raw)
To: Maciej Borzecki; +Cc: Paul Eggleton, Maciej Borzecki, openembedded-core
In-Reply-To: <7c765b6d3940a7b7dc9daeb32f712809a4b5464e.1479887010.git.maciej.borzecki@rndity.com>
Hi Maciej,
Thank you for the patchset!
The changes and the tests look good to me.
I have little suggestions, but most of them just a matter of taste, so
feel free to ignore them.
On Wed, Nov 23, 2016 at 08:46:33AM +0100, Maciej Borzecki wrote:
> wic has a new flag for setting a fixed parition size --fixed-size. Add
> tests that verify if partition is indeed sized properly and that errors
> are signaled when there is not enough space to fit partition data.
>
> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
> ---
> meta/lib/oeqa/selftest/wic.py | 69 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
> index ad783043b92130a023fd70120becec479c6253a7..45f68df1e74828e11401f57dd732a88a50dd1f00 100644
> --- a/meta/lib/oeqa/selftest/wic.py
> +++ b/meta/lib/oeqa/selftest/wic.py
> @@ -29,6 +29,7 @@ import unittest
> from glob import glob
> from shutil import rmtree
> from functools import wraps
> +from tempfile import NamedTemporaryFile
>
> from oeqa.selftest.base import oeSelfTest
> from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
> @@ -61,6 +62,8 @@ class Wic(oeSelfTest):
>
> def setUpLocal(self):
> """This code is executed before each test method."""
> + self.native_sysroot = get_bb_var('STAGING_DIR_NATIVE', 'core-image-minimal')
> +
> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
> is_x86 = arch in ['i586', 'i686', 'x86_64']
> if is_x86:
> @@ -378,3 +381,69 @@ class Wic(oeSelfTest):
> self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> % wic_cmd_vars).status)
> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
> +
> + def _make_fixed_size_wks(self, size):
> + """
> + Create a wks of an image with a single partition. Size of the partition is set
> + using --fixed-size flag. Returns a tuple: (path to wks file, wks image name)
> + """
> + with NamedTemporaryFile("w", suffix=".wks", delete=False) as tf:
> + wkspath = tf.name
> + tf.write("part " \
> + "--source rootfs --ondisk hda --align 4 --fixed-size %d "
> + "--fstype=ext4\n" % size)
> + wksname = os.path.splitext(os.path.basename(wkspath))[0]
> +
> + return (wkspath, wksname)
Would 'return wkspath, wksname' be a bit more readable?
> +
> + def test_fixed_size(self):
> + """
> + Test creation of a simple image with partition size controlled through
> + --fixed-size flag
> + """
> + wkspath, wksname = self._make_fixed_size_wks(200)
> +
> + wic_cmd_vars = {
> + 'wks': wkspath,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars).status)
> + os.remove(wkspath)
> + wicout = glob(self.resultdir + "%s-*direct" % wksname)
> + self.assertEqual(1, len(wicout))
> +
> + wicimg = wicout[0]
> +
> + # verify partition size with wic
> + res = runCmd("parted -m %s unit mib p 2>/dev/null" % wicimg,
> + ignore_status=True,
> + native_sysroot=self.native_sysroot)
> + self.assertEqual(0, res.status)
> +
> + # parse parted output which looks like this:
> + # BYT;\n
> + # /var/tmp/wic/build/tmpfwvjjkf_-201611101222-hda.direct:200MiB:file:512:512:msdos::;\n
> + # 1:0.00MiB:200MiB:200MiB:ext4::;\n
> + partlns = res.output.splitlines()[2:]
> +
> + self.assertEqual(1, len(partlns))
> + self.assertEqual("1:0.00MiB:200MiB:200MiB:ext4::;", partlns[0])
> +
> + def test_fixed_size_error(self):
> + """
> + Test creation of a simple image with partition size controlled through
> + --fixed-size flag. The size of partition is intentionally set to 1MiB
> + in order to trigger an error in wic.
> + """
> + wkspath, wksname = self._make_fixed_size_wks(1)
> +
> + wic_cmd_vars = {
> + 'wks': wkspath,
> + 'image': self.OE_IMAGE,
> + }
> + self.assertEqual(1, runCmd("wic create %(wks)s -e %(image)s" \
> + % wic_cmd_vars, ignore_status=True).status)
> + os.remove(wkspath)
> + wicout = glob(self.resultdir + "%s-*direct" % wksname)
> + self.assertEqual(0, len(wicout))
--
Regards,
Ed
^ permalink raw reply
* Re: [PATCH v4 5/7] wic: selftest: do not repeat core-image-minimal
From: Maciej Borzęcki @ 2016-11-23 11:39 UTC (permalink / raw)
To: Ed Bartosh
Cc: Paul Eggleton, Maciej Borzecki,
Patches and discussions about the oe-core layer
In-Reply-To: <20161123112356.GA12545@linux.intel.com>
On Wed, Nov 23, 2016 at 12:23 PM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> On Wed, Nov 23, 2016 at 08:46:31AM +0100, Maciej Borzecki wrote:
>> Replace repeated core-image-minimal with Wic class field.
>>
>> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
>> ---
>> meta/lib/oeqa/selftest/wic.py | 111 +++++++++++++++++++++++++++---------------
>> 1 file changed, 73 insertions(+), 38 deletions(-)
>>
>> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
>> index 2db14445956bc5adcf1e755844bbdb69edcb468f..37ed2c6de5a7f22f982f921476fa392304995b2e 100644
>> --- a/meta/lib/oeqa/selftest/wic.py
>> +++ b/meta/lib/oeqa/selftest/wic.py
>> @@ -57,6 +57,8 @@ class Wic(oeSelfTest):
>> resultdir = "/var/tmp/wic/build/"
>> image_is_ready = False
>>
>> + OE_IMAGE = "core-image-minimal"
>> +
>> def setUpLocal(self):
>> """This code is executed before each test method."""
>> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
>> @@ -75,7 +77,7 @@ class Wic(oeSelfTest):
>> tools += ' syslinux syslinux-native'
>> bitbake(tools)
>>
>> - bitbake('core-image-minimal')
>> + bitbake(self.OE_IMAGE)
>> Wic.image_is_ready = True
> I'd agree with Ross here - it looks less readable.
> How it would look if we decide to add test case for another image?
>
The usual way would be to:
class WicSatoImage(Wic):
OE_IMAGE = "core-image-sato"
But I think you make a fair point. The patch introduces unnecessary
complexity, and is not really needed right now. I'll drop this patch if next
version will be necessary.
Can you take a look at the rest of the patchset as well?
Thanks,
--
Maciej Borzecki
RnDity
^ permalink raw reply
* Re: [PATCH v4 7/7] wic: selftest: add tests for --fixed-size partition flags
From: Maciej Borzęcki @ 2016-11-23 11:47 UTC (permalink / raw)
To: Ed Bartosh
Cc: Paul Eggleton, Maciej Borzecki,
Patches and discussions about the oe-core layer
In-Reply-To: <20161123113630.GB12545@linux.intel.com>
On Wed, Nov 23, 2016 at 12:36 PM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> Hi Maciej,
>
> Thank you for the patchset!
> The changes and the tests look good to me.
> I have little suggestions, but most of them just a matter of taste, so
> feel free to ignore them.
>
> On Wed, Nov 23, 2016 at 08:46:33AM +0100, Maciej Borzecki wrote:
>> wic has a new flag for setting a fixed parition size --fixed-size. Add
>> tests that verify if partition is indeed sized properly and that errors
>> are signaled when there is not enough space to fit partition data.
>>
>> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
>> ---
>> meta/lib/oeqa/selftest/wic.py | 69 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 69 insertions(+)
>>
>> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
>> index ad783043b92130a023fd70120becec479c6253a7..45f68df1e74828e11401f57dd732a88a50dd1f00 100644
>> --- a/meta/lib/oeqa/selftest/wic.py
>> +++ b/meta/lib/oeqa/selftest/wic.py
>> @@ -29,6 +29,7 @@ import unittest
>> from glob import glob
>> from shutil import rmtree
>> from functools import wraps
>> +from tempfile import NamedTemporaryFile
>>
>> from oeqa.selftest.base import oeSelfTest
>> from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
>> @@ -61,6 +62,8 @@ class Wic(oeSelfTest):
>>
>> def setUpLocal(self):
>> """This code is executed before each test method."""
>> + self.native_sysroot = get_bb_var('STAGING_DIR_NATIVE', 'core-image-minimal')
>> +
>> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
>> is_x86 = arch in ['i586', 'i686', 'x86_64']
>> if is_x86:
>> @@ -378,3 +381,69 @@ class Wic(oeSelfTest):
>> self.assertEqual(0, runCmd("wic create %(wks)s -e %(image)s" \
>> % wic_cmd_vars).status)
>> self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
>> +
>> + def _make_fixed_size_wks(self, size):
>> + """
>> + Create a wks of an image with a single partition. Size of the partition is set
>> + using --fixed-size flag. Returns a tuple: (path to wks file, wks image name)
>> + """
>> + with NamedTemporaryFile("w", suffix=".wks", delete=False) as tf:
>> + wkspath = tf.name
>> + tf.write("part " \
>> + "--source rootfs --ondisk hda --align 4 --fixed-size %d "
>> + "--fstype=ext4\n" % size)
>> + wksname = os.path.splitext(os.path.basename(wkspath))[0]
>> +
>> + return (wkspath, wksname)
> Would 'return wkspath, wksname' be a bit more readable?
Agreed.
--
Maciej Borzecki
RnDity
^ permalink raw reply
* Re: migrating simple tarballs over to OE recipes?
From: Ulf Magnusson @ 2016-11-23 12:00 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611230633180.8293@ca624034.mitel.com>
On Wed, Nov 23, 2016 at 12:34 PM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
> On Wed, 23 Nov 2016, Burton, Ross wrote:
>
>>
>> On 23 November 2016 at 10:42, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> colleague has a pile of tarballs that were used to customize an x86
>> centos system, wants to move all that to OE with as little fuss as
>> possible, i guess the simplest way is to just create recipes that have
>> the same tarball in the files/ directory, and write a trivial
>> do_install() task that untars it into the root fs, yes?
>>
>>
>> Pretty much, yeah.
>>
>> If you've a large pile and they're all effectively the same then a
>> little class can automate it even more.
>
> already going down that road, just wanted to make sure i hadn't
> overlooked something obvious.
>
> rday
bin_package.bbclass might be useful as well, especially if the files
are already arranged like in the rootfs inside the tarballs.
Cheers,
Ulf
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Ed Bartosh @ 2016-11-23 12:08 UTC (permalink / raw)
To: Kristian Amlie; +Cc: Eduard Bartosh, openembedded-core
In-Reply-To: <6913e4bf-96dc-eefa-d214-9df5cde181b8@mender.io>
On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
> On 22/11/16 12:10, Patrick Ohly wrote:
> >> ...
> >
> > All of these introduce some special mechanism. Let me propose something
> > that might integrate better with the existing tooling:
> >
> > The "rootfs" directory gets redefined as representing the entire virtual
> > file system. When creating a disk image, it gets split up into different
> > partitions based on the image configuration.
> >
> > For example, the /home or /data directories in the rootfs could hold the
> > content that in some image configurations goes into separate partitions.
> >
> > The advantage of this approach is that the tooling for staging content
> > for image creation does not need to be changed. The same staged content
> > then can be used to create different images, potentially even using
> > different partition layouts.
>
> That's a very good idea. I think it beats all of my suggestions!
>
> > To implement this approach with wic, wic needs to be taught how to
> > exclude directories from the main rootfs. Ideally, the mkfs.* tools
> > should also support that without having to make an intermediate copy of
> > the files for a certain partition, but initially wic could create
> > temporary directory trees.
>
> Yes, some work would be needed here, but ultimately it would be contained within wic and related tools, which is a good thing.
>
I support the idea. Let's discuss the details of implementation and
create a bug in bugzilla to track the development
This can be done by extending existing rootfs plugin. It should be able
to do 2 things:
- populate content of one rootfs directory to the partition. We can
extend syntax of --rootfs-dir parameter to specify optional directory path to use
- exclude rootfs directories when populating partitions. I'd propose to
introduce --exclude-dirs wks parser option to handle this.
Example of wks file with proposed new options:
part / --source rootfs --rootfs-dir=core-image-minimal --ondisk sda --fstype=ext4 --label root --align 1024 --exclude-dirs data --exclude-dirs home
part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024
part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk sda --fstype=ext4 --label data --align 1024
Does this make sense?
Any other ideas?
--
Regards,
Ed
^ permalink raw reply
* [PATCH 1/2] conf: Remove redundant toasterconf.json file
From: Michael Wood @ 2016-11-23 12:24 UTC (permalink / raw)
To: openembedded-core; +Cc: toaster
We no longer use this file to start toaster. Toaster's configuration is
setup by Toaster itself using the standard Django data fixtures.
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
---
meta/conf/toasterconf.json | 77 ----------------------------------------------
1 file changed, 77 deletions(-)
delete mode 100644 meta/conf/toasterconf.json
diff --git a/meta/conf/toasterconf.json b/meta/conf/toasterconf.json
deleted file mode 100644
index 796125b..0000000
--- a/meta/conf/toasterconf.json
+++ /dev/null
@@ -1,77 +0,0 @@
-{
- "config": {
- "MACHINE" : "qemux86",
- "DISTRO" : "nodistro",
- "DL_DIR" : "${TOPDIR}/../downloads",
- "IMAGE_FSTYPES": "ext4 jffs2 tar.bz2",
- "IMAGE_INSTALL_append": "",
- "PACKAGE_CLASSES": "package_rpm",
- "SSTATE_DIR" : "${TOPDIR}/../sstate-cache"
- },
- "layersources": [
- {
- "name": "Local OpenEmbedded",
- "sourcetype": "local",
- "apiurl": "../../",
- "branches": ["HEAD", "master"],
- "layers": [
- {
- "name": "openembedded-core",
- "local_path": "meta",
- "vcs_url": "remote:origin",
- "dirpath": "meta"
- }
- ]
- },
- {
- "name": "OpenEmbedded",
- "sourcetype": "layerindex",
- "apiurl": "http://layers.openembedded.org/layerindex/api/",
- "branches": ["master"]
- },
- {
- "name": "Imported layers",
- "sourcetype": "imported",
- "apiurl": "",
- "branches": ["master", "HEAD"]
-
- }
- ],
- "bitbake" : [
- {
- "name": "master",
- "giturl": "git://git.openembedded.org/bitbake",
- "branch": "master",
- "dirpath": ""
- },
- {
- "name": "HEAD",
- "giturl": "git://git.openembedded.org/bitbake",
- "branch": "HEAD",
- "dirpath": ""
- }
- ],
-
- "defaultrelease": "master",
-
- "releases": [
- {
- "name": "master",
- "description": "OpenEmbedded master",
- "bitbake": "master",
- "branch": "master",
- "defaultlayers": [ "openembedded-core" ],
- "layersourcepriority": { "Imported layers": 99, "Local OpenEmbedded" : 10, "OpenEmbedded" : 0 },
- "helptext": "Toaster will run your builds using the tip of the <a href=\"http://cgit.openembedded.org/openembedded-core/log/\">OpenEmbedded master</a> branch, where active development takes place. This is not a stable branch, so your builds might not work as expected."
- },
- {
- "name": "local",
- "description": "Local OpenEmbedded",
- "bitbake": "HEAD",
- "branch": "HEAD",
- "defaultlayers": [ "openembedded-core" ],
- "layersourcepriority": { "Imported layers": 99, "Local OpenEmbedded" : 10, "OpenEmbedded" : 0 },
- "helptext": "Toaster will run your builds with the version of OpenEmbedded that you have cloned or downloaded to your computer."
- }
- ]
-}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] oe-selftest: toaster Remove redundant Toaster test
From: Michael Wood @ 2016-11-23 12:24 UTC (permalink / raw)
To: openembedded-core; +Cc: toaster
In-Reply-To: <1479903876-7268-1-git-send-email-michael.g.wood@intel.com>
This test has been ported to be run as part of Toaster's own tests.
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
---
meta/lib/oeqa/selftest/_toaster.py | 320 -------------------------------------
1 file changed, 320 deletions(-)
delete mode 100644 meta/lib/oeqa/selftest/_toaster.py
diff --git a/meta/lib/oeqa/selftest/_toaster.py b/meta/lib/oeqa/selftest/_toaster.py
deleted file mode 100644
index 15ea9df..0000000
--- a/meta/lib/oeqa/selftest/_toaster.py
+++ /dev/null
@@ -1,320 +0,0 @@
-import unittest
-import os
-import sys
-import shlex, subprocess
-import urllib.request, urllib.parse, urllib.error, subprocess, time, getpass, re, json, shlex
-
-import oeqa.utils.ftools as ftools
-from oeqa.selftest.base import oeSelfTest
-from oeqa.utils.commands import runCmd
-
-sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '../../../../', 'bitbake/lib/toaster')))
-os.environ.setdefault("DJANGO_SETTINGS_MODULE", "toastermain.settings")
-
-import toastermain.settings
-from django.db.models import Q
-from orm.models import *
-from oeqa.utils.decorators import testcase
-
-class ToasterSetup(oeSelfTest):
-
- def recipe_parse(self, file_path, var):
- for line in open(file_path,'r'):
- if line.find(var) > -1:
- val = line.split(" = ")[1].replace("\"", "").strip()
- return val
-
- def fix_file_path(self, file_path):
- if ":" in file_path:
- file_path=file_path.split(":")[2]
- return file_path
-
-class Toaster_DB_Tests(ToasterSetup):
-
- # Check if build name is unique - tc_id=795
- @testcase(795)
- def test_Build_Unique_Name(self):
- all_builds = Build.objects.all().count()
- distinct_builds = Build.objects.values('id').distinct().count()
- self.assertEqual(distinct_builds, all_builds, msg = 'Build name is not unique')
-
- # Check if build coocker log path is unique - tc_id=819
- @testcase(819)
- def test_Build_Unique_Cooker_Log_Path(self):
- distinct_path = Build.objects.values('cooker_log_path').distinct().count()
- total_builds = Build.objects.values('id').count()
- self.assertEqual(distinct_path, total_builds, msg = 'Build coocker log path is not unique')
-
- # Check if task order is unique for one build - tc=824
- @testcase(824)
- def test_Task_Unique_Order(self):
- builds = Build.objects.values('id')
- cnt_err = []
- for build in builds:
- total_task_order = Task.objects.filter(build = build['id']).values('order').count()
- distinct_task_order = Task.objects.filter(build = build['id']).values('order').distinct().count()
- if (total_task_order != distinct_task_order):
- cnt_err.append(build['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for build id: %s' % cnt_err)
-
- # Check task order sequence for one build - tc=825
- @testcase(825)
- def test_Task_Order_Sequence(self):
- builds = builds = Build.objects.values('id')
- cnt_err = []
- for build in builds:
- tasks = Task.objects.filter(Q(build = build['id']), ~Q(order = None), ~Q(task_name__contains = '_setscene')).values('id', 'order').order_by("order")
- cnt_tasks = 0
- for task in tasks:
- cnt_tasks += 1
- if (task['order'] != cnt_tasks):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if disk_io matches the difference between EndTimeIO and StartTimeIO in build stats - tc=828
- ### this needs to be updated ###
- #def test_Task_Disk_IO_TC828(self):
-
- # Check if outcome = 2 (SSTATE) then sstate_result must be 3 (RESTORED) - tc=832
- @testcase(832)
- def test_Task_If_Outcome_2_Sstate_Result_Must_Be_3(self):
- tasks = Task.objects.filter(outcome = 2).values('id', 'sstate_result')
- cnt_err = []
- for task in tasks:
- if (row['sstate_result'] != 3):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if outcome = 1 (COVERED) or 3 (EXISTING) then sstate_result must be 0 (SSTATE_NA) - tc=833
- @testcase(833)
- def test_Task_If_Outcome_1_3_Sstate_Result_Must_Be_0(self):
- tasks = Task.objects.filter(outcome__in = (1, 3)).values('id', 'sstate_result')
- cnt_err = []
- for task in tasks:
- if (task['sstate_result'] != 0):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if outcome is 0 (SUCCESS) or 4 (FAILED) then sstate_result must be 0 (NA), 1 (MISS) or 2 (FAILED) - tc=834
- @testcase(834)
- def test_Task_If_Outcome_0_4_Sstate_Result_Must_Be_0_1_2(self):
- tasks = Task.objects.filter(outcome__in = (0, 4)).values('id', 'sstate_result')
- cnt_err = []
- for task in tasks:
- if (task['sstate_result'] not in [0, 1, 2]):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if task_executed = TRUE (1), script_type must be 0 (CODING_NA), 2 (CODING_PYTHON), 3 (CODING_SHELL) - tc=891
- @testcase(891)
- def test_Task_If_Task_Executed_True_Script_Type_0_2_3(self):
- tasks = Task.objects.filter(task_executed = 1).values('id', 'script_type')
- cnt_err = []
- for task in tasks:
- if (task['script_type'] not in [0, 2, 3]):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if task_executed = TRUE (1), outcome must be 0 (SUCCESS) or 4 (FAILED) - tc=836
- @testcase(836)
- def test_Task_If_Task_Executed_True_Outcome_0_4(self):
- tasks = Task.objects.filter(task_executed = 1).values('id', 'outcome')
- cnt_err = []
- for task in tasks:
- if (task['outcome'] not in [0, 4]):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if task_executed = FALSE (0), script_type must be 0 - tc=890
- @testcase(890)
- def test_Task_If_Task_Executed_False_Script_Type_0(self):
- tasks = Task.objects.filter(task_executed = 0).values('id', 'script_type')
- cnt_err = []
- for task in tasks:
- if (task['script_type'] != 0):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Check if task_executed = FALSE (0) and build outcome = SUCCEEDED (0), task outcome must be 1 (COVERED), 2 (CACHED), 3 (PREBUILT), 5 (EMPTY) - tc=837
- @testcase(837)
- def test_Task_If_Task_Executed_False_Outcome_1_2_3_5(self):
- builds = Build.objects.filter(outcome = 0).values('id')
- cnt_err = []
- for build in builds:
- tasks = Task.objects.filter(build = build['id'], task_executed = 0).values('id', 'outcome')
- for task in tasks:
- if (task['outcome'] not in [1, 2, 3, 5]):
- cnt_err.append(task['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task id: %s' % cnt_err)
-
- # Key verification - tc=888
- @testcase(888)
- def test_Target_Installed_Package(self):
- rows = Target_Installed_Package.objects.values('id', 'target_id', 'package_id')
- cnt_err = []
- for row in rows:
- target = Target.objects.filter(id = row['target_id']).values('id')
- package = Package.objects.filter(id = row['package_id']).values('id')
- if (not target or not package):
- cnt_err.append(row['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for target installed package id: %s' % cnt_err)
-
- # Key verification - tc=889
- @testcase(889)
- def test_Task_Dependency(self):
- rows = Task_Dependency.objects.values('id', 'task_id', 'depends_on_id')
- cnt_err = []
- for row in rows:
- task_id = Task.objects.filter(id = row['task_id']).values('id')
- depends_on_id = Task.objects.filter(id = row['depends_on_id']).values('id')
- if (not task_id or not depends_on_id):
- cnt_err.append(row['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for task dependency id: %s' % cnt_err)
-
- # Check if build target file_name is populated only if is_image=true AND orm_build.outcome=0 then if the file exists and its size matches the file_size value
- ### Need to add the tc in the test run
- @testcase(1037)
- def test_Target_File_Name_Populated(self):
- builds = Build.objects.filter(outcome = 0).values('id')
- for build in builds:
- targets = Target.objects.filter(build_id = build['id'], is_image = 1).values('id')
- for target in targets:
- target_files = Target_Image_File.objects.filter(target_id = target['id']).values('id', 'file_name', 'file_size')
- cnt_err = []
- for file_info in target_files:
- target_id = file_info['id']
- target_file_name = file_info['file_name']
- target_file_size = file_info['file_size']
- if (not target_file_name or not target_file_size):
- cnt_err.append(target_id)
- else:
- if (not os.path.exists(target_file_name)):
- cnt_err.append(target_id)
- else:
- if (os.path.getsize(target_file_name) != target_file_size):
- cnt_err.append(target_id)
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for target image file id: %s' % cnt_err)
-
- # Key verification - tc=884
- @testcase(884)
- def test_Package_Dependency(self):
- cnt_err = []
- deps = Package_Dependency.objects.values('id', 'package_id', 'depends_on_id')
- for dep in deps:
- if (dep['package_id'] == dep['depends_on_id']):
- cnt_err.append(dep['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package dependency id: %s' % cnt_err)
-
- # Recipe key verification, recipe name does not depends on a recipe having the same name - tc=883
- @testcase(883)
- def test_Recipe_Dependency(self):
- deps = Recipe_Dependency.objects.values('id', 'recipe_id', 'depends_on_id')
- cnt_err = []
- for dep in deps:
- if (not dep['recipe_id'] or not dep['depends_on_id']):
- cnt_err.append(dep['id'])
- else:
- name = Recipe.objects.filter(id = dep['recipe_id']).values('name')
- dep_name = Recipe.objects.filter(id = dep['depends_on_id']).values('name')
- if (name == dep_name):
- cnt_err.append(dep['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for recipe dependency id: %s' % cnt_err)
-
- # Check if package name does not start with a number (0-9) - tc=846
- @testcase(846)
- def test_Package_Name_For_Number(self):
- packages = Package.objects.filter(~Q(size = -1)).values('id', 'name')
- cnt_err = []
- for package in packages:
- if (package['name'][0].isdigit() is True):
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check if package version starts with a number (0-9) - tc=847
- @testcase(847)
- def test_Package_Version_Starts_With_Number(self):
- packages = Package.objects.filter(~Q(size = -1)).values('id', 'version')
- cnt_err = []
- for package in packages:
- if (package['version'][0].isdigit() is False):
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check if package revision starts with 'r' - tc=848
- @testcase(848)
- def test_Package_Revision_Starts_With_r(self):
- packages = Package.objects.filter(~Q(size = -1)).values('id', 'revision')
- cnt_err = []
- for package in packages:
- if (package['revision'][0].startswith("r") is False):
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check the validity of the package build_id
- ### TC must be added in test run
- @testcase(1038)
- def test_Package_Build_Id(self):
- packages = Package.objects.filter(~Q(size = -1)).values('id', 'build_id')
- cnt_err = []
- for package in packages:
- build_id = Build.objects.filter(id = package['build_id']).values('id')
- if (not build_id):
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check the validity of package recipe_id
- ### TC must be added in test run
- @testcase(1039)
- def test_Package_Recipe_Id(self):
- packages = Package.objects.filter(~Q(size = -1)).values('id', 'recipe_id')
- cnt_err = []
- for package in packages:
- recipe_id = Recipe.objects.filter(id = package['recipe_id']).values('id')
- if (not recipe_id):
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check if package installed_size field is not null
- ### TC must be aded in test run
- @testcase(1040)
- def test_Package_Installed_Size_Not_NULL(self):
- packages = Package.objects.filter(installed_size__isnull = True).values('id')
- cnt_err = []
- for package in packages:
- cnt_err.append(package['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for package id: %s' % cnt_err)
-
- # Check if all layers requests return exit code is 200 - tc=843
- @testcase(843)
- def test_Layers_Requests_Exit_Code(self):
- layers = Layer.objects.values('id', 'layer_index_url')
- cnt_err = []
- for layer in layers:
- resp = urllib.request.urlopen(layer['layer_index_url'])
- if (resp.getcode() != 200):
- cnt_err.append(layer['id'])
- self.assertEqual(len(cnt_err), 0, msg = 'Errors for layer id: %s' % cnt_err)
-
- # Check if django server starts regardless of the timezone set on the machine - tc=905
- @testcase(905)
- def test_Start_Django_Timezone(self):
- current_path = os.getcwd()
- zonefilelist = []
- ZONEINFOPATH = '/usr/share/zoneinfo/'
- os.chdir("../bitbake/lib/toaster/")
- cnt_err = 0
- for filename in os.listdir(ZONEINFOPATH):
- if os.path.isfile(os.path.join(ZONEINFOPATH, filename)):
- zonefilelist.append(filename)
- for k in range(len(zonefilelist)):
- if k <= 5:
- files = zonefilelist[k]
- os.system("export TZ="+str(files)+"; python manage.py runserver > /dev/null 2>&1 &")
- time.sleep(3)
- pid = subprocess.check_output("ps aux | grep '[/u]sr/bin/python manage.py runserver' | awk '{print $2}'", shell = True)
- if pid:
- os.system("kill -9 "+str(pid))
- else:
- cnt_err.append(zonefilelist[k])
- self.assertEqual(cnt_err, 0, msg = 'Errors django server does not start with timezone: %s' % cnt_err)
- os.chdir(current_path)
--
2.7.4
^ permalink raw reply related
* what is the current equivalent for the apache "mod_auth_tkt" module?
From: Robert P. J. Day @ 2016-11-23 13:00 UTC (permalink / raw)
To: OE Core mailing list
colleague wants to add that to his build, but i don't see that
module anywhere. has it been superseded by something else? am i just
blind in not seeing it?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Kristian Amlie @ 2016-11-23 13:08 UTC (permalink / raw)
To: ed.bartosh; +Cc: Eduard Bartosh, openembedded-core
In-Reply-To: <20161123120816.GC12545@linux.intel.com>
On 23/11/16 13:08, Ed Bartosh wrote:
> On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
>> On 22/11/16 12:10, Patrick Ohly wrote:
>>>> ...
>>>
>>> All of these introduce some special mechanism. Let me propose something
>>> that might integrate better with the existing tooling:
>>>
>>> The "rootfs" directory gets redefined as representing the entire virtual
>>> file system. When creating a disk image, it gets split up into different
>>> partitions based on the image configuration.
>>>
>>> For example, the /home or /data directories in the rootfs could hold the
>>> content that in some image configurations goes into separate partitions.
>>>
>>> The advantage of this approach is that the tooling for staging content
>>> for image creation does not need to be changed. The same staged content
>>> then can be used to create different images, potentially even using
>>> different partition layouts.
>>
>> That's a very good idea. I think it beats all of my suggestions!
>>
>>> To implement this approach with wic, wic needs to be taught how to
>>> exclude directories from the main rootfs. Ideally, the mkfs.* tools
>>> should also support that without having to make an intermediate copy of
>>> the files for a certain partition, but initially wic could create
>>> temporary directory trees.
>>
>> Yes, some work would be needed here, but ultimately it would be contained within wic and related tools, which is a good thing.
>>
>
> I support the idea. Let's discuss the details of implementation and
> create a bug in bugzilla to track the development
Do you want me to create the ticket? (it'll be my first, so apologies in
advance if I omit something important)
> This can be done by extending existing rootfs plugin. It should be able
> to do 2 things:
>
> - populate content of one rootfs directory to the partition. We can
> extend syntax of --rootfs-dir parameter to specify optional directory path to use
>
> - exclude rootfs directories when populating partitions. I'd propose to
> introduce --exclude-dirs wks parser option to handle this.
>
> Example of wks file with proposed new options:
> part / --source rootfs --rootfs-dir=core-image-minimal --ondisk sda --fstype=ext4 --label root --align 1024 --exclude-dirs data --exclude-dirs home
> part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024
> part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk sda --fstype=ext4 --label data --align 1024
>
> Does this make sense?
Looks good. The only thing I would question is that, in the interest of
reducing redundancy, maybe we should omit --exclude-dirs and have wic
figure this out by combining all the entries, since "--exclude-dirs
<dir>" and the corresponding "part <dir>" will almost always come in
pairs. Possibly we could mark the "/" partition with one single
--no-overlapping-dirs to force wic to make this consideration. Or do you
think that's too magical?
(I haven't checked how feasible this is in the code btw)
--
Kristian
^ permalink raw reply
* [PATCH] insane: Add aarch64 baremetal mappings to the QA arch test
From: Alexandre Belloni @ 2016-11-23 13:03 UTC (permalink / raw)
To: openembedded-core
Add mappings for aarch64-elf and aarch64_be-elf to binary lookup table
which allows for the generation of baremetal toolchains.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
meta/classes/insane.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index a5c93f33ff53..d51e73eaf48f 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -63,6 +63,8 @@ def package_qa_get_machine_dict(d):
"arm" : (40, 0, 0, True, 32),
},
"elf" : {
+ "aarch64" : (183, 0, 0, True, 64),
+ "aarch64_be" :(183, 0, 0, False, 64),
"i586" : (3, 0, 0, True, 32),
"x86_64": (62, 0, 0, True, 64),
"epiphany": (4643, 0, 0, True, 32),
--
2.10.2
^ permalink raw reply related
* Re: Contents of non-rootfs partitions
From: Ed Bartosh @ 2016-11-23 13:22 UTC (permalink / raw)
To: Kristian Amlie; +Cc: Eduard Bartosh, openembedded-core
In-Reply-To: <5064cacc-e724-c7b8-9631-3d961c5a29f6@mender.io>
On Wed, Nov 23, 2016 at 02:08:28PM +0100, Kristian Amlie wrote:
> On 23/11/16 13:08, Ed Bartosh wrote:
> > On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
> >> On 22/11/16 12:10, Patrick Ohly wrote:
> >>>> ...
> >>>
> >>> All of these introduce some special mechanism. Let me propose something
> >>> that might integrate better with the existing tooling:
> >>>
> >>> The "rootfs" directory gets redefined as representing the entire virtual
> >>> file system. When creating a disk image, it gets split up into different
> >>> partitions based on the image configuration.
> >>>
> >>> For example, the /home or /data directories in the rootfs could hold the
> >>> content that in some image configurations goes into separate partitions.
> >>>
> >>> The advantage of this approach is that the tooling for staging content
> >>> for image creation does not need to be changed. The same staged content
> >>> then can be used to create different images, potentially even using
> >>> different partition layouts.
> >>
> >> That's a very good idea. I think it beats all of my suggestions!
> >>
> >>> To implement this approach with wic, wic needs to be taught how to
> >>> exclude directories from the main rootfs. Ideally, the mkfs.* tools
> >>> should also support that without having to make an intermediate copy of
> >>> the files for a certain partition, but initially wic could create
> >>> temporary directory trees.
> >>
> >> Yes, some work would be needed here, but ultimately it would be contained within wic and related tools, which is a good thing.
> >>
> >
> > I support the idea. Let's discuss the details of implementation and
> > create a bug in bugzilla to track the development
>
> Do you want me to create the ticket? (it'll be my first, so apologies in
> advance if I omit something important)
>
> > This can be done by extending existing rootfs plugin. It should be able
> > to do 2 things:
> >
> > - populate content of one rootfs directory to the partition. We can
> > extend syntax of --rootfs-dir parameter to specify optional directory path to use
> >
> > - exclude rootfs directories when populating partitions. I'd propose to
> > introduce --exclude-dirs wks parser option to handle this.
> >
> > Example of wks file with proposed new options:
> > part / --source rootfs --rootfs-dir=core-image-minimal --ondisk sda --fstype=ext4 --label root --align 1024 --exclude-dirs data --exclude-dirs home
> > part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024
> > part /home --source rootfs --rootfs-dir=core-image-minimal:/data --ondisk sda --fstype=ext4 --label data --align 1024
> >
> > Does this make sense?
>
> Looks good. The only thing I would question is that, in the interest of
> reducing redundancy, maybe we should omit --exclude-dirs and have wic
> figure this out by combining all the entries, since "--exclude-dirs
> <dir>" and the corresponding "part <dir>" will almost always come in
> pairs. Possibly we could mark the "/" partition with one single
> --no-overlapping-dirs to force wic to make this consideration. Or do you
> think that's too magical?
>
Tt's quite implicit from my point of view. However, if people like it we
can implement it this way.
> (I haven't checked how feasible this is in the code btw)
I think it would be much easier to implement --exclude-dirs.
BTW, it will also allow to exclude directories from any partition, not just from
root, e.g. to use --exclude dirs this way:
part /data --source rootfs --rootfs-dir=core-image-minimal:/home --ondisk sda --fstype=ext4 --label data --align 1024 --exclude-dirs cache --exclude-dirs tmp
--
Regards,
Ed
^ permalink raw reply
* Re: [PATCH v4 5/7] wic: selftest: do not repeat core-image-minimal
From: Ed Bartosh @ 2016-11-23 13:26 UTC (permalink / raw)
To: Maciej Borzęcki
Cc: Paul Eggleton, Maciej Borzecki,
Patches and discussions about the oe-core layer
In-Reply-To: <CAD4b0_JG7ApGTZ7BxHtfv53Z-T_jKQxN9fYrEBpcHvWaiRFsKg@mail.gmail.com>
On Wed, Nov 23, 2016 at 12:39:26PM +0100, Maciej Borzęcki wrote:
> On Wed, Nov 23, 2016 at 12:23 PM, Ed Bartosh <ed.bartosh@linux.intel.com> wrote:
> > On Wed, Nov 23, 2016 at 08:46:31AM +0100, Maciej Borzecki wrote:
> >> Replace repeated core-image-minimal with Wic class field.
> >>
> >> Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
> >> ---
> >> meta/lib/oeqa/selftest/wic.py | 111 +++++++++++++++++++++++++++---------------
> >> 1 file changed, 73 insertions(+), 38 deletions(-)
> >>
> >> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
> >> index 2db14445956bc5adcf1e755844bbdb69edcb468f..37ed2c6de5a7f22f982f921476fa392304995b2e 100644
> >> --- a/meta/lib/oeqa/selftest/wic.py
> >> +++ b/meta/lib/oeqa/selftest/wic.py
> >> @@ -57,6 +57,8 @@ class Wic(oeSelfTest):
> >> resultdir = "/var/tmp/wic/build/"
> >> image_is_ready = False
> >>
> >> + OE_IMAGE = "core-image-minimal"
> >> +
> >> def setUpLocal(self):
> >> """This code is executed before each test method."""
> >> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
> >> @@ -75,7 +77,7 @@ class Wic(oeSelfTest):
> >> tools += ' syslinux syslinux-native'
> >> bitbake(tools)
> >>
> >> - bitbake('core-image-minimal')
> >> + bitbake(self.OE_IMAGE)
> >> Wic.image_is_ready = True
> > I'd agree with Ross here - it looks less readable.
> > How it would look if we decide to add test case for another image?
> >
>
> The usual way would be to:
>
> class WicSatoImage(Wic):
> OE_IMAGE = "core-image-sato"
>
> But I think you make a fair point. The patch introduces unnecessary
> complexity, and is not really needed right now. I'll drop this patch if next
> version will be necessary.
>
> Can you take a look at the rest of the patchset as well?
>
I already did. The patchset looks good to me. Thank you for your work!
+1
--
Regards,
Ed
^ permalink raw reply
* Re: [PATCH] libpcap: Fix build when PACKAGECONFIG ipv6 is not enable
From: Christopher Larson @ 2016-11-23 13:41 UTC (permalink / raw)
To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CAP9ODKr7igkbbvi2tu6qwAv+gVLbty0HrkfF30cDtiG+5xqdWQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
On Wed, Nov 23, 2016 at 3:00 AM, Otavio Salvador <
otavio.salvador@ossystems.com.br> wrote:
> On Thu, Nov 17, 2016 at 2:24 PM, Christopher Larson <clarson@kergoth.com>
> wrote:
> >
> > On Thu, Nov 17, 2016 at 9:21 AM, Fabio Berton
> > <fabio.berton@ossystems.com.br> wrote:
> >>
> >> No, I created a patch, git format-patch and then edit generated files
> with
> >> Upstream-Status tag and added to recipe. Is this wrong?
> >
> >
> > As I indicated in my first reply, it’s best to put the tag outside the
> > generated patch (above it, or below the —-), as it isn’t part of the
> commit,
> > only part of the patch file. It’s minor, and you don’t need to re-submit,
> > but in general the tag is not part of the commit message. For example, if
> > your patch was applied to a git repository with git-am, it’d be in the
> > commit message, which should not be the case.
>
> To be honest, there a many files which does as Fabio did and I also
> personally do as well. I don't like it outside of the commit log as it
> looks out of context.
>
> If someone is getting the patch file, it is expected they will review
> it and not blindly apply it on upstream repository.
I don’t feel too strongly about it, if that’s the consensus, that’s fine, I
just wanted to open up a dialogue on the subject. Thanks.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 2111 bytes --]
^ permalink raw reply
* Re: Contents of non-rootfs partitions
From: Ed Bartosh @ 2016-11-23 13:44 UTC (permalink / raw)
To: Kristian Amlie; +Cc: Eduard Bartosh, openembedded-core
In-Reply-To: <5064cacc-e724-c7b8-9631-3d961c5a29f6@mender.io>
On Wed, Nov 23, 2016 at 02:08:28PM +0100, Kristian Amlie wrote:
> On 23/11/16 13:08, Ed Bartosh wrote:
> > On Tue, Nov 22, 2016 at 12:54:52PM +0100, Kristian Amlie wrote:
> >> On 22/11/16 12:10, Patrick Ohly wrote:
> >>>> ...
> >>>
> >>> All of these introduce some special mechanism. Let me propose something
> >>> that might integrate better with the existing tooling:
> >>>
> >>> The "rootfs" directory gets redefined as representing the entire virtual
> >>> file system. When creating a disk image, it gets split up into different
> >>> partitions based on the image configuration.
> >>>
> >>> For example, the /home or /data directories in the rootfs could hold the
> >>> content that in some image configurations goes into separate partitions.
> >>>
> >>> The advantage of this approach is that the tooling for staging content
> >>> for image creation does not need to be changed. The same staged content
> >>> then can be used to create different images, potentially even using
> >>> different partition layouts.
> >>
> >> That's a very good idea. I think it beats all of my suggestions!
> >>
> >>> To implement this approach with wic, wic needs to be taught how to
> >>> exclude directories from the main rootfs. Ideally, the mkfs.* tools
> >>> should also support that without having to make an intermediate copy of
> >>> the files for a certain partition, but initially wic could create
> >>> temporary directory trees.
> >>
> >> Yes, some work would be needed here, but ultimately it would be contained within wic and related tools, which is a good thing.
> >>
> >
> > I support the idea. Let's discuss the details of implementation and
> > create a bug in bugzilla to track the development
>
> Do you want me to create the ticket? (it'll be my first, so apologies in
> advance if I omit something important)
>
Yes, please create an issue in bugzilla and assign it to me. Don't
worry. If you miss something other people will point to in in the
comments :)
--
Regards,
Ed
^ permalink raw reply
* [Patch 1/7] webkitgtk: Use MIPS MACHINE_OVERRIDES
From: Zubair Lutfullah Kakakhel @ 2016-11-23 13:47 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20161123134733.38276-1-Zubair.Kakakhel@imgtec.com>
The mipsarch* MACHINE_OVERRIDES can be used to pass the same
parameters to MIPS pre-R2 and R6 ISA variants.
Use them to reduce duplication in supporting MIPS R6 ISA.
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
---
meta/recipes-sato/webkit/webkitgtk_2.14.1.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
index 1f2166c..3637e05 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
@@ -77,8 +77,7 @@ EXTRA_OECMAKE_append_armv4 = " -DENABLE_JIT=OFF "
# binutils 2.25.1 has a bug on aarch64:
# https://sourceware.org/bugzilla/show_bug.cgi?id=18430
EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF "
-EXTRA_OECMAKE_append_mips = " -DUSE_LD_GOLD=OFF "
-EXTRA_OECMAKE_append_mips64 = " -DUSE_LD_GOLD=OFF "
+EXTRA_OECMAKE_append_mipsarch = " -DUSE_LD_GOLD=OFF "
EXTRA_OECMAKE_append_toolchain-clang = " -DUSE_LD_GOLD=OFF "
# JIT not supported on MIPS either
@@ -106,4 +105,5 @@ ARM_INSTRUCTION_SET_armv7ve = "thumb"
# WebKit2-4.0: ../../libgpg-error-1.21/src/posix-lock.c:119: get_lock_object: Assertion `!"sizeof lock obj"' failed.
# qemu: uncaught target signal 6 (Aborted) - core dumped
-EXTRA_OECMAKE_append_mips64 = " -DENABLE_INTROSPECTION=OFF -DENABLE_GTKDOC=OFF"
+EXTRA_OECMAKE_append_mipsarchn32 = " -DENABLE_INTROSPECTION=OFF -DENABLE_GTKDOC=OFF"
+EXTRA_OECMAKE_append_mipsarchn64 = " -DENABLE_INTROSPECTION=OFF -DENABLE_GTKDOC=OFF"
--
2.10.2
^ permalink raw reply related
* [Patch 2/7] qemu: Disable qemu on target for MIPS
From: Zubair Lutfullah Kakakhel @ 2016-11-23 13:47 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20161123134733.38276-1-Zubair.Kakakhel@imgtec.com>
Disable building qemu on MIPS N64 and N32.
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
---
meta/recipes-devtools/qemu/qemu_2.7.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/qemu/qemu_2.7.0.bb b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
index cef181d..2b5cc5e 100644
--- a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
@@ -19,7 +19,8 @@ SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2"
SRC_URI[md5sum] = "08d4d06d1cb598efecd796137f4844ab"
SRC_URI[sha256sum] = "326e739506ba690daf69fc17bd3913a6c313d9928d743bd8eddb82f403f81e53"
-COMPATIBLE_HOST_class-target_mips64 = "null"
+COMPATIBLE_HOST_mipsarchn32 = "null"
+COMPATIBLE_HOST_mipsarchn64 = "null"
do_install_append() {
# Prevent QA warnings about installed ${localstatedir}/run
--
2.10.2
^ permalink raw reply related
* [Patch 0/7] MIPS: sprinkle some patches
From: Zubair Lutfullah Kakakhel @ 2016-11-23 13:47 UTC (permalink / raw)
To: openembedded-core
I'm running bitbake -k world using poky for various machine
configurations from https://github.com/MIPS/meta-img
Here are some patches
Regards,
ZubairLK
Zubair Lutfullah Kakakhel (7):
webkitgtk: Use MIPS MACHINE_OVERRIDES
qemu: Disable qemu on target for MIPS
valgrind: Use MIPS MACHINE_OVERRIDES
python-numpy: Use MIPS MACHINE_OVERRIDES to reduce duplication
gmp: Disable assembly for MIPS R6
perf: Add EXTRA_LDFLAGS for MIPS N32
ghostscript: Use MIPS MACHINE_OVERRIDES for objarch.h
.../{mips64n32 => mipsarchn32eb}/_numpyconfig.h | 0
.../files/{mips64 => mipsarchn32eb}/config.h | 0
.../files/mipsarchn32el/_numpyconfig.h | 31 +++++
.../python-numpy/files/mipsarchn32el/config.h | 138 +++++++++++++++++++++
.../files/{mips64 => mipsarchn64eb}/_numpyconfig.h | 0
.../files/{mips64n32 => mipsarchn64eb}/config.h | 0
.../files/mipsarchn64el/_numpyconfig.h | 32 +++++
.../python-numpy/files/mipsarchn64el/config.h | 138 +++++++++++++++++++++
.../files/{mips => mipsarcho32eb}/_numpyconfig.h | 0
.../files/{mips => mipsarcho32eb}/config.h | 0
.../files/{mipsel => mipsarcho32el}/config.h | 0
.../files/{mipsel => mipsarcho32el}/numpyconfig.h | 0
.../python-numpy/python-numpy_1.11.2.bb | 16 ++-
.../python-numpy/python3-numpy_1.11.2.bb | 16 ++-
meta/recipes-devtools/qemu/qemu_2.7.0.bb | 3 +-
meta/recipes-devtools/valgrind/valgrind_3.12.0.bb | 7 +-
.../{mips64 => mipsarchn32eb}/objarch.h | 0
.../{mips64el => mipsarchn32el}/objarch.h | 0
.../{mips64n32 => mipsarchn64eb}/objarch.h | 0
.../{mips64eln32 => mipsarchn64el}/objarch.h | 0
.../ghostscript/{mips => mipsarcho32eb}/objarch.h | 0
.../{mipsel => mipsarcho32el}/objarch.h | 0
meta/recipes-kernel/perf/perf.bb | 7 ++
meta/recipes-sato/webkit/webkitgtk_2.14.1.bb | 6 +-
meta/recipes-support/gmp/gmp_6.1.1.bb | 1 +
25 files changed, 381 insertions(+), 14 deletions(-)
rename meta/recipes-devtools/python-numpy/files/{mips64n32 => mipsarchn32eb}/_numpyconfig.h (100%)
rename meta/recipes-devtools/python-numpy/files/{mips64 => mipsarchn32eb}/config.h (100%)
create mode 100644 meta/recipes-devtools/python-numpy/files/mipsarchn32el/_numpyconfig.h
create mode 100644 meta/recipes-devtools/python-numpy/files/mipsarchn32el/config.h
rename meta/recipes-devtools/python-numpy/files/{mips64 => mipsarchn64eb}/_numpyconfig.h (100%)
rename meta/recipes-devtools/python-numpy/files/{mips64n32 => mipsarchn64eb}/config.h (100%)
create mode 100644 meta/recipes-devtools/python-numpy/files/mipsarchn64el/_numpyconfig.h
create mode 100644 meta/recipes-devtools/python-numpy/files/mipsarchn64el/config.h
rename meta/recipes-devtools/python-numpy/files/{mips => mipsarcho32eb}/_numpyconfig.h (100%)
rename meta/recipes-devtools/python-numpy/files/{mips => mipsarcho32eb}/config.h (100%)
rename meta/recipes-devtools/python-numpy/files/{mipsel => mipsarcho32el}/config.h (100%)
rename meta/recipes-devtools/python-numpy/files/{mipsel => mipsarcho32el}/numpyconfig.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mips64 => mipsarchn32eb}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mips64el => mipsarchn32el}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mips64n32 => mipsarchn64eb}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mips64eln32 => mipsarchn64el}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mips => mipsarcho32eb}/objarch.h (100%)
rename meta/recipes-extended/ghostscript/ghostscript/{mipsel => mipsarcho32el}/objarch.h (100%)
--
2.10.2
^ permalink raw reply
* [Patch 3/7] valgrind: Use MIPS MACHINE_OVERRIDES
From: Zubair Lutfullah Kakakhel @ 2016-11-23 13:47 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20161123134733.38276-1-Zubair.Kakakhel@imgtec.com>
The mipsarch* MACHINE_OVERRIDES can be used to pass the same
parameters to MIPS pre-R2 and R6 ISA variants.
Use them to reduce duplication in supporting MIPS R6 ISA.
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
---
meta/recipes-devtools/valgrind/valgrind_3.12.0.bb | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.12.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.12.0.bb
index 2474bbc..637b723 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.12.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.12.0.bb
@@ -36,8 +36,11 @@ COMPATIBLE_HOST_armv4 = 'null'
COMPATIBLE_HOST_armv5 = 'null'
COMPATIBLE_HOST_armv6 = 'null'
-# valgrind doesn't like mips soft float
-COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains("TARGET_FPU", "soft", "null", ".*-linux", d)}"
+# Disable for some MIPS variants
+COMPATIBLE_HOST_mipsarcho32 = "${@bb.utils.contains("TARGET_FPU", "soft", "null", ".*-linux", d)}"
+COMPATIBLE_HOST_mipsarchn32 = 'null'
+COMPATIBLE_HOST_mipsarchn64 = "${@bb.utils.contains("TARGET_FPU", "soft", "null", ".*-linux", d)}"
+COMPATIBLE_HOST_mipsarchr6 = 'null'
inherit autotools ptest
--
2.10.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox