<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/poky.git/scripts, branch 2.8_M1</title>
<subtitle>Mirror of git.yoctoproject.org/poky</subtitle>
<id>https://git.enea.com/cgit/linux/poky.git/atom?h=2.8_M1</id>
<link rel='self' href='https://git.enea.com/cgit/linux/poky.git/atom?h=2.8_M1'/>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/'/>
<updated>2019-06-10T16:38:10+00:00</updated>
<entry>
<title>recipetool: add python3 support</title>
<updated>2019-06-10T16:38:10+00:00</updated>
<author>
<name>Maciej Pijanowski</name>
<email>maciej.pijanowski@3mdeb.com</email>
</author>
<published>2019-06-08T19:13:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=bb59bcd016bdd815809ac10df45d61c364c46df0'/>
<id>urn:sha1:bb59bcd016bdd815809ac10df45d61c364c46df0</id>
<content type='text'>
Add support for generating python3 recipes using the recipetool / devtool.
Drop python2 support at the same time.

Tested with:

oe-selftest -r recipetool.RecipetoolTest

[YOCTO #13264]

(From OE-Core rev: d8b2f58974482b3b1ccc65c5f93104d0d7ba87bc)

Signed-off-by: Maciej Pijanowski &lt;maciej.pijanowski@3mdeb.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>runqemu: QB_FSINFO to support fstype wic images</title>
<updated>2019-06-10T16:38:10+00:00</updated>
<author>
<name>Adrian Freihofer</name>
<email>adrian.freihofer@siemens.com</email>
</author>
<published>2019-06-09T12:03:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=0e4c79a7c4dae93fb1b12e8c0a59e8252e3f4b71'/>
<id>urn:sha1:0e4c79a7c4dae93fb1b12e8c0a59e8252e3f4b71</id>
<content type='text'>
wic images are handled as vmtype images. Starting qemu with "-kernel"
parameter and an image of type wic is not supported. Especially for
"-machine virt" the combination of wic with -kernel parameter would
be beneficial.

The new parameter QB_FSINFO allows to pass image type specific flags to
runqemu. QB_FSINFO is a space separated list of parameters. Parameters are
structured according to the following pattern: image-type:flag.

For now two parameters are supported:
- wic:no-kernel-in-fs
  The wic image is treated as rootfs only image. A -kernel option is
  passed to qemu.
- wic:kernel-in-fs
  The wic image is treated as VM image including a bootloader and a
  kernel. This is still the default behavior.

Example:
QB_DEFAULT_FSTYPE = "wic"
QB_FSINFO = "wic:no-kernel-in-fs"
QB_KERNEL_ROOT = "/dev/vda1"
QB_SYSTEM_NAME = "qemu-system-aarch64"
QB_MACHINE = "-machine virt"
...

[YOCTO #13336]

(From OE-Core rev: 2aa79a67affd22dfa37e4c2945c6ab0c86321f98)

Signed-off-by: Adrian Freihofer &lt;adrian.freihofer@siemens.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wic/filemap: handle FIGETBSZ failing</title>
<updated>2019-06-08T15:01:41+00:00</updated>
<author>
<name>Ross Burton</name>
<email>ross.burton@intel.com</email>
</author>
<published>2019-06-07T11:05:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=ca4cdfcd18b4d48e22c9b4ae0af0a4ed8991a6f1'/>
<id>urn:sha1:ca4cdfcd18b4d48e22c9b4ae0af0a4ed8991a6f1</id>
<content type='text'>
Some file systems don't support fetching the block size (notably the file system
Docker uses for containers), so handle the iotctl() failing and raise the
expected error.

(From OE-Core rev: 3757073726a00c5250556aae3d0daac76b88085e)

Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wic/engine: include .wks.in in wic search and list</title>
<updated>2019-06-07T08:11:49+00:00</updated>
<author>
<name>Chee Yang Lee</name>
<email>chee.yang.lee@intel.com</email>
</author>
<published>2019-06-05T15:38:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=cc083399ce3378148d7e1d08a4df52b14e79903e'/>
<id>urn:sha1:cc083399ce3378148d7e1d08a4df52b14e79903e</id>
<content type='text'>
allow wic to list and search for kickstart file in .wks.in extension.
basename show by wic list images to fully exclude extension.

(From OE-Core rev: 2c0a292a790ad069648e37b1b29fcea656fcf3e4)

Signed-off-by: Chee Yang Lee &lt;chee.yang.lee@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>runqemu: Add the support to pass multi ports to tcpserial parameter</title>
<updated>2019-06-07T08:11:48+00:00</updated>
<author>
<name>Kevin Hao</name>
<email>kexin.hao@windriver.com</email>
</author>
<published>2019-06-06T07:11:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=e5f2684d60025fbe205d1974ba89341d1d5408be'/>
<id>urn:sha1:e5f2684d60025fbe205d1974ba89341d1d5408be</id>
<content type='text'>
In some cases(such as the oeqa's qemurunner), we need to setup multi
serial devices via the '-serial 127.0.0.1:xx" and the order of them
is significant. The mixing use of "tcpserial" and "-serial 127.0.0.1:xx"
cause ambiguous issues and we can't fix it by only adjusting the order
of them. So add the support to pass multi ports to the tcpserial
parameter, this will make sure that the order of setting up the serial
is really what we want.

[YOCTO Bug 13309]

(From OE-Core rev: 766c3b56e5071b5a5a64e88df6d3abe5232dd958)

Signed-off-by: Kevin Hao &lt;kexin.hao@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>resulttool: Remove prints if no tests occur</title>
<updated>2019-06-04T22:09:24+00:00</updated>
<author>
<name>Jon Mason</name>
<email>jdmason@kudzu.us</email>
</author>
<published>2019-06-03T23:19:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=b6ca6ac564cb4b8c88d811690c2b7487b58f06b4'/>
<id>urn:sha1:b6ca6ac564cb4b8c88d811690c2b7487b58f06b4</id>
<content type='text'>
Printing the lack of a test is not necessary (per feedback).  Remove
this from the template to quieten it.

(From OE-Core rev: b1fe6ae66360e160eeaeafe456536f335a0eab60)

Signed-off-by: Jon Mason &lt;jdmason@kudzu.us&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>resulttool/manualexecution: Enable creation of test case configuration</title>
<updated>2019-06-04T08:09:42+00:00</updated>
<author>
<name>sangeeta jain</name>
<email>sangeeta.jain@intel.com</email>
</author>
<published>2019-06-03T08:17:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=d9cb1c472c1151751f08060dc0ef1122d1abd109'/>
<id>urn:sha1:d9cb1c472c1151751f08060dc0ef1122d1abd109</id>
<content type='text'>
Allow the creation of test case configuration file based on user inputs.
Where this testcase configuration file will be used by the the manual
execution to run selected test cases for a module rather than compulsory
run all test cases in manual json file.

(From OE-Core rev: 73d2a747c17779da0ca972da776b3cf02c2e1cbc)

Signed-off-by: sangeeta jain &lt;sangeeta.jain@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>resulttool: modify to be multi-machine</title>
<updated>2019-06-04T08:09:42+00:00</updated>
<author>
<name>Jon Mason</name>
<email>jdmason@kudzu.us</email>
</author>
<published>2019-06-02T18:29:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=cb153e8da8897080e128d7e29d6a1f48e1190fdf'/>
<id>urn:sha1:cb153e8da8897080e128d7e29d6a1f48e1190fdf</id>
<content type='text'>
Currently, the code will sum all of the different machine results into a
single report of the tests results.  This can lead to confusion as to
which machine may be experiencing issues.  Modify the code to store the
results in a per machine basis and report them accordingly.

(From OE-Core rev: 16d4031ea5df8a4ddfdb937d35464c09e1abd10e)

Signed-off-by: Jon Mason &lt;jdmason@kudzu.us&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>runqemu: Add support for kvm on aarch64</title>
<updated>2019-05-31T14:36:20+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2019-05-30T22:08:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=a07a6a74159d9fa2d0ca52c990f69ceac7c237d8'/>
<id>urn:sha1:a07a6a74159d9fa2d0ca52c990f69ceac7c237d8</id>
<content type='text'>
The main issue is to make the x86 checks apply to x86 targets only. We may
end up with better checks on other architectures but this adapts the code to
allow for that and its still controlled by whether QB_CPU_KVM is set.

The code needed minor refactoring so the qemu-system-XXX name is set
earlier so the kvm code can use it.

(From OE-Core rev: 06c473a0127f19b76d0f647b87873944add1e331)

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wic: bootimg-efi: add label source parameter</title>
<updated>2019-05-30T11:37:03+00:00</updated>
<author>
<name>Chee Yang Lee</name>
<email>chee.yang.lee@intel.com</email>
</author>
<published>2019-05-30T07:30:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/poky.git/commit/?id=01543538d1139ab4244760f254b4c5289a50a4ea'/>
<id>urn:sha1:01543538d1139ab4244760f254b4c5289a50a4ea</id>
<content type='text'>
Add new source parameter label to allow custom boot.conf/grub.cfg label,
so far it's hardcoded to "Boot".

Default label to "Boot" for systemd-boot and blank for grub-efi when source
parameter label are not set.

(From OE-Core rev: 7a0aab1aa31e66e6bc94c04c2f6c1043b64a8967)

Signed-off-by: Chee Yang Lee &lt;chee.yang.lee at intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
</entry>
</feed>
