Re: [OE-core] [PATCH] bzip2: Add test suite for bzip2

[Rahul Kumar]

Hi Randy,

Thanks for your  feedback.
As per your suggestion,I am working on that.

currently my patch has Upstream-Status: Inappropriate.

Since I am not aware of the patch submission process on bzip2, I posted a
query on bzip2 mailing list (2 days back)  but I did not get any response
from there.
If they are not responding, in this case shall i keep Upstream-Status:
Inappropriate and send the v2 to oe-core  Or  should i wait for his
response?
Or
Do you have any idea how to submit the patch for bzip2-test repo.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Tue, Apr 14, 2020 at 12:48 AM Randy MacLeod 
wrote:

> On 2020-04-13 1:22 p.m., Rahul Kumar wrote:
>
> Hi Randy,
>
> Kindly find the attached bzip2 ptest logs file.
>
> Hi Rahul,
>
> Most or even all of the tests that fail are due to:
>
>   bzip2: No space left on device
>
> For a [de]compression utility ptest suite, it's certainly reasonable
> to add extra space to the test image:
>
> https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE
>
> Make note of what how much extra space is needed in your commit log since
> we don't have a way for ptests to declare this and for it to be added
> automatically.
>
> It would also be really nice to see a summary of your ptest result
> in the long log. For example in my recent update to rsyslog in meta-oe:
>1ec13d7d9 rsyslog: 8.1911.0 -> 8.2002.0
> ...
>
> On qemux86-64/kvm the ptest results with extra filesystem
> space and a timeout of 800 seconds are:
>  1911   2002
>  TOTAL:   389408
>  PASS:339357
>  SKIP: 39 39
>  XFAIL: 0  0
>  FAIL: 11 12
>  XPASS: 0  0
>  ERROR: 0  0
>
> I probably should have listed the extra space used! oops. :)
>
> I answered your Question here .
> Kindly take a look and feel free to point out if i am wrong at any place
> and let me know if i missed anything.
> ==
> > +
> > +modify run-tests script to write PASS/FAIL as expected by the ptest
> infrastructure
> > +
> > +Signed-off-by: Rahul Kumar 
> > +---
> > + run-tests.sh | 83
> +++-
> > + 1 file changed, 43 insertions(+), 40 deletions(-)
> > +
> > +diff --git a/run-tests.sh b/run-tests.sh
> > +index 1ba8c27..1eff62a 100755
> > +--- a/run-tests.sh
> >  b/run-tests.sh
> > +@@ -10,7 +10,7 @@
> > + VALGRIND="valgrind"
> > + VALGRIND_ARGS="-q --error-exitcode=9"
> > + BZIP2="bzip2"
> > +-TESTS_DIR="."
> > ++TESTS_DIR="./bzip2-tests"
>
> Can you explain why you did this? Maybe upstream would accept it ?
>
> Ans:
> we need to parse the TEST_DIR Path because we are running runtest.sh
> script outside the bzip2-tests directory.
> But I figured out a more convenient way for this.
> I will parse the TEST_DIR path during running the runscript.sh.
>
> I can implement this by adding below line in makefile.am file.
> ./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"
>
> Ah good.
>
>
> In Next version of patch I will implement it.
>
> ===
>
> > + IGNORE_MD5=0
> > +
> > + for i in "$@"
> > +@@ -40,21 +40,21 @@ case $i in
> > + esac
> > + done
> > +
> > +-if ! type "valgrind" > /dev/null; then
> > ++if ! type "valgrind" > /dev/null 2>&1; then
> > +   VALGRIND=""
> > +   VALGRIND_ARGS=""
> > + fi
>
> Explanation:
>
>if ! type "valgrind" > /dev/null;
>suppose if valgrind is not present in my image at that time it is
> showing
> ./bzip2-tests/run-tests.sh: line 43: type: valgrind: not found
>
>Since we are displaying a message in script that valgrind is used or
> not.
>
>So i redirect the output
>BY Modifying this line with "if ! type "valgrind" > /dev/null 2>&1"
>
> ==
>
> > + echo "Testing ${BZIP2} in directory ${TESTS_DIR}"
> > + if [ "$VALGRIND" != "" ]; then
> > +-  echo "  using valgrind"
> > ++  echo "Using valgrind: Yes"
> > + else
> > +-  echo "  NOT using valgrind"
> > ++  echo "Using valgrind: No"
> > + fi
> > + if [[ ${IGNORE_MD5} -eq 0 ]]; then
> > +-  echo "  checking md5 sums"
> > ++  echo "Checking md5 sums: Yes"
> > + else
> > +-  echo "  NOT checking md5 sums"
> > ++  echo "Checking md5 sums: No"
> > + fi
> > +
>
> Explanation:
> I Simply modified valgrind and md5sum messages with Yes/No
>
> I is worth seeing if upstream will accept the change, IMO.
>
>
> ==
>
> > + # Remove any left over tesfilecopies from previous runs first.
> > +@@ -76,16 +76,16 @@ while IFS= read -r -d '' bzfile; do
> > +   echo "Processing ${bzfile}"
> > +
> > +   # Decompress it.
> > +-  echo "  Decompress..."
> > ++  # echo "  Decompress..."
>
> Explanation:
> Initially for each file It is printing Decompress...
> I think which is not required to display in ptest logs so i comment it out.
>
> Does it cause a problem?
> We try to minimize our changes so if it's 

Re: [OE-core] [zeus][PATCH 00/13] zeus pull request - cover letter only

[Anuj Mittal]

Ping

On Fri, 2020-04-10 at 11:15 +0800, Anuj Mittal wrote:
> Please pull these changes for zeus. a-full passed on autobuilder.
> 
> Thanks,
> 
> Anuj
> 
> The following changes since commit
> 0743dcd0cd70dee87a49d3bcd017168352e60982:
> 
>   wic/direct: reserve 2 sector for extended partition (2020-03-26
> 07:33:07 +0800)
> 
> are available in the Git repository at:
> 
>   git://push.openembedded.org/openembedded-core-contrib stable/zeus-
> next
> 
> Jan Luebbe (5):
>   lib/oe/package_manager: make sure to not remove packages in apt
> install
>   lib/oe/package_manager: fix handling of last package
>   lib/oe/package_manager: collect provided package names when using
> debs
>   lib/oe/package_manager: avoid installing provided packages via apt
>   lib/oe/package_manager: don't try to rm /var/lib/opkg
> 
> Jeremy Puhlman (1):
>   busybox: on upgrade save busybox if it is the last shell
> 
> Joshua Watt (1):
>   u-boot-tools: Split out inc file
> 
> Marek Vasut (2):
>   waffle: no need to depend on target python3
>   lttng-modules: update to 2.10.14
> 
> Paul Barker (3):
>   kernel-yocto.bbclass: Support config fragments with externalsrc
>   perf: Fix externalsrc support
>   kernelsrc.bbclass: Fix externalsrc support
> 
> haiqing (1):
>   glib-2.0: fix CVE-2020-6750
> 
>  meta/classes/kernel-yocto.bbclass |   3 +-
>  meta/classes/kernelsrc.bbclass|   2 +-
>  meta/lib/oe/package_manager.py|  37 +-
>  meta/recipes-bsp/u-boot/u-boot-tools.inc  |  65 ++
>  .../u-boot/u-boot-tools_2019.07.bb|  67 +-
>  meta/recipes-core/busybox/busybox.inc |  43 +
>  .../glib-2.0/glib-2.0/CVE-2020-6750.patch | 741
> ++
>  meta/recipes-core/glib-2.0/glib-2.0_2.60.7.bb |   1 +
>  meta/recipes-graphics/waffle/waffle_1.6.0.bb  |   5 +
>  ...ops-when-trace-sunrpc_task-events-in.patch |  94 ---
>  ...rpc_clnt-dereference-in-rpc_task_que.patch |  44 --
>  ...rpc-use-signed-integer-for-client-id.patch | 105 ---
>  ...nrpc-introduce-lttng_get_clid-helper.patch | 130 ---
>  ...es_2.10.11.bb => lttng-modules_2.10.14.bb} |  12 +-
>  meta/recipes-kernel/perf/perf.bb  |   2 +-
>  15 files changed, 887 insertions(+), 464 deletions(-)
>  create mode 100644 meta/recipes-bsp/u-boot/u-boot-tools.inc
>  create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2020-
> 6750.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0001-Fix-
> SUNRPC-Fix-oops-when-trace-sunrpc_task-events-in.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0002-Fix-
> sunrpc-null-rpc_clnt-dereference-in-rpc_task_que.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0003-Fix-
> sunrpc-use-signed-integer-for-client-id.patch
>  delete mode 100644 meta/recipes-kernel/lttng/lttng-modules/0004-
> sunrpc-introduce-lttng_get_clid-helper.patch
>  rename meta/recipes-kernel/lttng/{lttng-modules_2.10.11.bb => lttng-
> modules_2.10.14.bb} (75%)
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137203): 
https://lists.openembedded.org/g/openembedded-core/message/137203
Mute This Topic: https://lists.openembedded.org/mt/72913281/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] looking for clarification re: "rm_work" features and variations

[Richard Purdie]

On Fri, 2020-04-10 at 13:52 -0400, Robert P. J. Day wrote:
>   was looking to expand on the whole "rm_work" documentation, only to
> discover i was profoundly ignorant of some of its features (don't say
> it :-).
> 
>   so, first, there's the basic stuff (which is already in the YP
> documentation):
> 
>   INHERIT += "rm_work"
>   RM_WORK_EXCLUDE += "pkg1 pkg2 ..."
> 
> then in rm_work.bbclass, i see this:
> 
>   # Recipes can also configure which entries in their ${WORKDIR}
>   # are preserved besides temp, which already gets excluded by
> default
>   # because it contains logs:
>   # do_install_append () {
>   # echo "bar" >${WORKDIR}/foo
>   # }
>   # RM_WORK_EXCLUDE_ITEMS += "foo"
>   RM_WORK_EXCLUDE_ITEMS = "temp"
> 
> of which i was totally unaware, so let's start there. the above
> suggests that recipes can configure, selectively, what in their
> WORKDIR gets preserved, but it makes little sense to set that sort of
> thing in an actual recipe file; it's clearly the sort of thing a
> developer would put in a local.conf.

I'd suggest this is more of a class internal and not really aimed at
the general user. There are things which someone might set here but its
not common usage.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137202): 
https://lists.openembedded.org/g/openembedded-core/message/137202
Mute This Topic: https://lists.openembedded.org/mt/72927184/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-04-13 1:22 p.m., Rahul Kumar wrote:

Hi Randy,

Kindly find the attached bzip2 ptest logs file.


Hi Rahul,

Most or even all of the tests that fail are due to:

  bzip2: No space left on device

For a [de]compression utility ptest suite, it's certainly reasonable
to add extra space to the test image:
https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE

Make note of what how much extra space is needed in your commit log since
we don't have a way for ptests to declare this and for it to be added 
automatically.


It would also be really nice to see a summary of your ptest result
in the long log. For example in my recent update to rsyslog in meta-oe:
   1ec13d7d9 rsyslog: 8.1911.0 -> 8.2002.0
...

    On qemux86-64/kvm the ptest results with extra filesystem
    space and a timeout of 800 seconds are:
 1911   2002
 TOTAL:   389    408
 PASS:    339    357
 SKIP: 39 39
 XFAIL: 0  0
 FAIL: 11 12
 XPASS: 0  0
 ERROR: 0  0

I probably should have listed the extra space used! oops. :)


I answered your Question here .
Kindly take a look and feel free to point out if i am wrong at any 
place and let me know if i missed anything.

==
> +
> +modify run-tests script to write PASS/FAIL as expected by the ptest 
infrastructure

> +
> +Signed-off-by: Rahul Kumar >

> +---
> + run-tests.sh | 83 
+++-

> + 1 file changed, 43 insertions(+), 40 deletions(-)
> +
> +diff --git a/run-tests.sh b/run-tests.sh
> +index 1ba8c27..1eff62a 100755
> +--- a/run-tests.sh
>  b/run-tests.sh
> +@@ -10,7 +10,7 @@
> + VALGRIND="valgrind"
> + VALGRIND_ARGS="-q --error-exitcode=9"
> + BZIP2="bzip2"
> +-TESTS_DIR="."
> ++TESTS_DIR="./bzip2-tests"

Can you explain why you did this? Maybe upstream would accept it ?

Ans:
we need to parse the TEST_DIR Path because we are running runtest.sh 
script outside the bzip2-tests directory.

But I figured out a more convenient way for this.
I will parse the TEST_DIR path during running the runscript.sh.

I can implement this by adding below line in makefile.am 
 file.

./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"

Ah good.


In Next version of patch I will implement it.

===

> + IGNORE_MD5=0
> +
> + for i in "$@"
> +@@ -40,21 +40,21 @@ case $i in
> + esac
> + done
> +
> +-if ! type "valgrind" > /dev/null; then
> ++if ! type "valgrind" > /dev/null 2>&1; then
> +   VALGRIND=""
> +   VALGRIND_ARGS=""
> + fi

Explanation:

   if ! type "valgrind" > /dev/null;
   suppose if valgrind is not present in my image at that time it is 
showing

./bzip2-tests/run-tests.sh: line 43: type: valgrind: not found

   Since we are displaying a message in script that valgrind is used 
or not.


   So i redirect the output
   BY Modifying this line with "if ! type "valgrind" > /dev/null 2>&1"

==

> + echo "Testing ${BZIP2} in directory ${TESTS_DIR}"
> + if [ "$VALGRIND" != "" ]; then
> +-  echo "  using valgrind"
> ++  echo "Using valgrind: Yes"
> + else
> +-  echo "  NOT using valgrind"
> ++  echo "Using valgrind: No"
> + fi
> + if [[ ${IGNORE_MD5} -eq 0 ]]; then
> +-  echo "  checking md5 sums"
> ++  echo "Checking md5 sums: Yes"
> + else
> +-  echo "  NOT checking md5 sums"
> ++  echo "Checking md5 sums: No"
> + fi
> +

Explanation:
I Simply modified valgrind and md5sum messages with Yes/No

I is worth seeing if upstream will accept the change, IMO.


==

> + # Remove any left over tesfilecopies from previous runs first.
> +@@ -76,16 +76,16 @@ while IFS= read -r -d '' bzfile; do
> +   echo "Processing ${bzfile}"
> +
> +   # Decompress it.
> +-  echo "  Decompress..."
> ++  # echo "  Decompress..."

Explanation:
Initially for each file It is printing Decompress...
I think which is not required to display in ptest logs so i comment it 
out.

Does it cause a problem?
We try to minimize our changes so if it's just aesthetic, don't change it.


==
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-    md5sum --check --status ${md5file} < ${file} \
> +-      || { echo "!!! md5sum doesn't match decompressed file";
> ++    md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} 
md5sum Matched"; } \

> ++      || { echo "FAIL: ${bzfile} md5sum Matched";
> +            badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
> +            nogood=$[${nogood}+1]; conti

Explanation:
for md5sum there is no short form option for --status option.
use of --status is "don't output anything, status code shows success"

md5sum -c ${md5file} < ${copy}
so i removed the --status option due to this below line is coming in 
ptest log

-: OK


The discrete md5sum doesn't have a short form of --status and

busybox md5sum only supports '-s'; that's a shame.

I guess we'd need to drop the argument for now but
this is another case where perhaps upstream bzip2 

Re: [OE-core] [PATCH] bzip2: Add test suite for bzip2

[Rahul Kumar]

Hi Randy,

Kindly find the attached bzip2 ptest logs file.
I answered your Question here .
Kindly take a look and feel free to point out if i am wrong at any place
and let me know if i missed anything.
==
> +
> +modify run-tests script to write PASS/FAIL as expected by the ptest
infrastructure
> +
> +Signed-off-by: Rahul Kumar 
> +---
> + run-tests.sh | 83
+++-
> + 1 file changed, 43 insertions(+), 40 deletions(-)
> +
> +diff --git a/run-tests.sh b/run-tests.sh
> +index 1ba8c27..1eff62a 100755
> +--- a/run-tests.sh
>  b/run-tests.sh
> +@@ -10,7 +10,7 @@
> + VALGRIND="valgrind"
> + VALGRIND_ARGS="-q --error-exitcode=9"
> + BZIP2="bzip2"
> +-TESTS_DIR="."
> ++TESTS_DIR="./bzip2-tests"

Can you explain why you did this? Maybe upstream would accept it ?

Ans:
we need to parse the TEST_DIR Path because we are running runtest.sh script
outside the bzip2-tests directory.
But I figured out a more convenient way for this.
I will parse the TEST_DIR path during running the runscript.sh.

I can implement this by adding below line in makefile.am file.
./bzip2-tests/run-tests.sh --tests-dir="$(PWD)/bzip2-tests"

In Next version of patch I will implement it.

===

> + IGNORE_MD5=0
> +
> + for i in "$@"
> +@@ -40,21 +40,21 @@ case $i in
> + esac
> + done
> +
> +-if ! type "valgrind" > /dev/null; then
> ++if ! type "valgrind" > /dev/null 2>&1; then
> +   VALGRIND=""
> +   VALGRIND_ARGS=""
> + fi

Explanation:

   if ! type "valgrind" > /dev/null;
   suppose if valgrind is not present in my image at that time it is
showing
./bzip2-tests/run-tests.sh: line 43: type: valgrind: not found

   Since we are displaying a message in script that valgrind is used or
not.

   So i redirect the output
   BY Modifying this line with "if ! type "valgrind" > /dev/null 2>&1"

==

> + echo "Testing ${BZIP2} in directory ${TESTS_DIR}"
> + if [ "$VALGRIND" != "" ]; then
> +-  echo "  using valgrind"
> ++  echo "Using valgrind: Yes"
> + else
> +-  echo "  NOT using valgrind"
> ++  echo "Using valgrind: No"
> + fi
> + if [[ ${IGNORE_MD5} -eq 0 ]]; then
> +-  echo "  checking md5 sums"
> ++  echo "Checking md5 sums: Yes"
> + else
> +-  echo "  NOT checking md5 sums"
> ++  echo "Checking md5 sums: No"
> + fi
> +

Explanation:
I Simply modified valgrind and md5sum messages with Yes/No

==

> + # Remove any left over tesfilecopies from previous runs first.
> +@@ -76,16 +76,16 @@ while IFS= read -r -d '' bzfile; do
> +   echo "Processing ${bzfile}"
> +
> +   # Decompress it.
> +-  echo "  Decompress..."
> ++  # echo "  Decompress..."

Explanation:
Initially for each file It is printing Decompress...
I think which is not required to display in ptest logs so i comment it out.

==
> +   if [[ ${IGNORE_MD5} -ne 1 ]]; then
> +-md5sum --check --status ${md5file} < ${file} \
> +-  || { echo "!!! md5sum doesn't match decompressed file";
> ++md5sum -c ${md5file} < ${file} && { echo "PASS: ${bzfile} md5sum
Matched"; } \
> ++  || { echo "FAIL: ${bzfile} md5sum Matched";
> +badtests=("${badtests[@]}" $"${file} md5sum doesn't match")
> +nogood=$[${nogood}+1]; conti

Explanation:
for md5sum there is no short form option for --status option.
use of --status is "don't output anything, status code shows success"

md5sum -c ${md5file} < ${copy}
so i removed the --status option due to this below line is coming in ptest
log
-: OK

==

+   echo "Bad results, look for !!! in the logs above"
+   printf ' - %s\n' "${badtests[@]}"
+-  exit 1
+ fi
+--

Explanation:
if some test failed then script is returning with exit 1 status due to this
at the end of ptest below message is printing
make: *** [Makefile:14: runtest] Error 1

logs wil looks like below if script returning with exit 1 status

PASS: Correctly found data integrity errors in
./bzip2-tests/lbzip2/void.bz2.bad during decompress (small)

Correctly found all bad file data integrity errors.

Bad results, look for !!! in the logs above
 - ./bzip2-tests/commons-compress/zip64support.tar.bz2 bad decompress result
 - ./bzip2-tests/go/regexp/re2-exhaustive.txt.bz2 bad decompress result
 - ./bzip2-tests/lbzip2/idx89.bz2 bad decompress result
 - ./bzip2-tests/lbzip2/ch255.bz2 bad decompress result
 - ./bzip2-tests/pyflate/45MB-fb.bz2 bad decompress result
 - ./bzip2-tests/pyflate/45MB-00.bz2 bad decompress result
make: *** [Makefile:14: runtest] Error 1

ERROR: Exit status is 512
DURATION: 31
END: /usr/lib/bzip2/ptest
2020-04-13T16:05
STOP: ptest-runner
root@qemux86-64:~#

To avoid "make: *** [Makefile:14: runtest] Error 1" messgae
I removed exit 1 line from the script.
May be i am wrong please suggest me i should keep it or remove.

==

>  file://configure.ac;subdir=${BP} \
>  file://Makefile.am;subdir=${BP} \
>  file://run-ptest \
> +
file://0001-bzip2-modify-run-tests-script.patch;patchdir=${WORKDIR}/git \
>  "
> +
> 

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 309
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues
being in "3.1" and then "3.2".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137199): 
https://lists.openembedded.org/g/openembedded-core/message/137199
Mute This Topic: https://lists.openembedded.org/mt/72991248/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] u-boot.inc: install u-boot-initial-env as ${PN}-initial-env in $D and $DEPLOYDIR

[Otavio Salvador]

On Sun, Apr 12, 2020 at 7:43 PM Denys Dmytriyenko  wrote:
> From: Denys Dmytriyenko 
>
> The common u-boot.inc can be used by multiple recipes in the same build for
> different cores and/or multiple stages of the bootloader. Naming initial-env
> with ${PN} prefix avoids clashes in deploy and rootfs between those recipes.
>
> This fixes 69b3b093079c2ca2744d6c02747c5d1b5d3e7ecf that unconditionally
> builds, installs and deploys u-boot-initial-env in the common u-boot.inc.
>
> Signed-off-by: Denys Dmytriyenko 
> ---

Acked-by: Otavio Salvador 



-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137198): 
https://lists.openembedded.org/g/openembedded-core/message/137198
Mute This Topic: https://lists.openembedded.org/mt/72975859/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] u-boot: Restore valid default environment for running system

[Denys Dmytriyenko]

On Mon, Apr 13, 2020 at 08:47:21AM -0300, Otavio Salvador wrote:
> On Sun, Apr 12, 2020 at 6:07 PM Denys Dmytriyenko  wrote:
> > > +
> > > +# Generate the uboot-initial-env
> > > +oe_runmake -C ${S} O=${B} u-boot-initial-env
> >
> > So, why is this enabled unconditionally? Should this be in 
> > UBOOT_MAKE_TARGET?
> >
> > I use this .inc file for building different u-boot pieces by different 
> > recipes
> > (main u-boot, SPL, etc., etc.) controlling the build with UBOOT_MAKE_TARGET
> > below. Now each of those generate u-boot-initial-env and they clash in 
> > deploy.
> 
> They clash? how so? it generates different filenames so should not have a 
> clash.

Different filenames? It's always u-boot-initial-env in deploy and /etc...
I already sent a patch last night to actually do different names...


> > > This change is late in the cycle but it is critical in my opinion.
> > >
> > > The lack of default environment as well as the configuration for the
> > > tool is a regression from the previous release and this mitigates it.
> >
> > Well, I would rather live w/o env rather than unable to build u-boot at 
> > all...
> 
> Please provide more information as I did not figure out what is not
> working by your report.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137197): 
https://lists.openembedded.org/g/openembedded-core/message/137197
Mute This Topic: https://lists.openembedded.org/mt/72715096/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] recommended way to "/bin/sh" -> "/sbin/nologin" various accounts in new image?

[Robert P. J. Day]

  colleague just pointed out that, in a new core-image-minimal, the
base-passwd recipe loads up /etc/passwd (based on initial
passwd.master file) with various accounts that really don't merit a
login shell of /bin/sh:
...
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/bin/sh
man:*:6:12:man:/var/cache/man:/bin/sh
lp:*:7:7:lp:/var/spool/lpd:/bin/sh
mail:*:8:8:mail:/var/mail:/bin/sh
news:*:9:9:news:/var/spool/news:/bin/sh
...

  it is, of course, trivial to add a couple patches to
base-passwd.bbappend to reduce a lot of those to using /sbin/nologin
rather than /bin/sh, but is there a simpler way? is there a variable
which you can set to, say, the passwd accounts to be weakened this
way? or do people just patch the passwd.master file? or is there yet
another alternative?

rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137196): 
https://lists.openembedded.org/g/openembedded-core/message/137196
Mute This Topic: https://lists.openembedded.org/mt/72986212/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v3] u-boot: Restore valid default environment for running system

[Otavio Salvador]

On Sun, Apr 12, 2020 at 6:07 PM Denys Dmytriyenko  wrote:
> > +
> > +# Generate the uboot-initial-env
> > +oe_runmake -C ${S} O=${B} u-boot-initial-env
>
> So, why is this enabled unconditionally? Should this be in UBOOT_MAKE_TARGET?
>
> I use this .inc file for building different u-boot pieces by different recipes
> (main u-boot, SPL, etc., etc.) controlling the build with UBOOT_MAKE_TARGET
> below. Now each of those generate u-boot-initial-env and they clash in deploy.

They clash? how so? it generates different filenames so should not have a clash.

> > This change is late in the cycle but it is critical in my opinion.
> >
> > The lack of default environment as well as the configuration for the
> > tool is a regression from the previous release and this mitigates it.
>
> Well, I would rather live w/o env rather than unable to build u-boot at all...

Please provide more information as I did not figure out what is not
working by your report.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137195): 
https://lists.openembedded.org/g/openembedded-core/message/137195
Mute This Topic: https://lists.openembedded.org/mt/72715096/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] wic: use Filesystem UUID when expand swap partition

[Lee Chee Yang]

From: Lee Chee Yang 

part.get("uuid") return the Partition UUID from the partition
table instead of Filesystem UUID. This lead to swap partition
UUID not match/change when wic write expand swap partition.

change it to read the filesystem UUID using blkid. The output
from blkid should looks like this:
wic-partvzhiwq3s: LABEL="swap1" UUID="04e55c19-3f3f-4491-9e32-44eea8daa827" 
VERSION="1" TYPE="swap" USAGE="other"

[YOCTO #13313]

Signed-off-by: Lee Chee Yang 
---
 scripts/lib/wic/engine.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py
index 9ff4394..018815b 100644
--- a/scripts/lib/wic/engine.py
+++ b/scripts/lib/wic/engine.py
@@ -280,7 +280,7 @@ class Disk:
 def __getattr__(self, name):
 """Get path to the executable in a lazy way."""
 if name in ("mdir", "mcopy", "mdel", "mdeltree", "sfdisk", "e2fsck",
-"resize2fs", "mkswap", "mkdosfs", "debugfs"):
+"resize2fs", "mkswap", "mkdosfs", "debugfs","blkid"):
 aname = "_%s" % name
 if aname not in self.__dict__:
 setattr(self, aname, find_executable(name, self.paths))
@@ -543,7 +543,8 @@ class Disk:
 logger.info("creating swap partition {}".format(pnum))
 label = part.get("name")
 label_str = "-L {}".format(label) if label else ''
-uuid = part.get("uuid")
+out = exec_cmd("{} --probe {}".format(self.blkid, 
self._get_part_image(pnum)))
+uuid = 
out[out.index("UUID=\"")+6:out.index("UUID=\"")+42]
 uuid_str = "-U {}".format(uuid) if uuid else ''
 with open(partfname, 'w') as sparse:
 os.ftruncate(sparse.fileno(), part['size'] * 
self._lsector_size)
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137194): 
https://lists.openembedded.org/g/openembedded-core/message/137194
Mute This Topic: https://lists.openembedded.org/mt/72983928/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] oeqa/runtime/weston: Enhance weston tests

[Alexander Kanavin]

Thanks, now one step closer to deprecating x11 :)

I'm thinking of rebasing all images used by autobuilder (e.g. -ptest, -sdk)
to be based off core-image-weston in 3.2 timeframe. The only sato image
would be core-image-sato itself.

Alex

On Mon, 13 Apr 2020 at 10:49, Yeoh Ee Peng  wrote:

> Existing weston test available make sure that a process
> for weston-desktop-shell exist when image boot up.
>
> Enhance weston tests by:
>  - execute weston-info to make sure weston interface(s)
>are initialized
>  - execute weston and make sure it can initialize a
>new wayland compositor
>
> [YOCTO# 10690]
>
> Signed-off-by: Yeoh Ee Peng 
> ---
>  meta/lib/oeqa/runtime/cases/weston.py | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/meta/lib/oeqa/runtime/cases/weston.py
> b/meta/lib/oeqa/runtime/cases/weston.py
> index f32599a..f79ed64 100644
> --- a/meta/lib/oeqa/runtime/cases/weston.py
> +++ b/meta/lib/oeqa/runtime/cases/weston.py
> @@ -6,6 +6,8 @@ from oeqa.runtime.case import OERuntimeTestCase
>  from oeqa.core.decorator.depends import OETestDepends
>  from oeqa.core.decorator.data import skipIfNotFeature
>  from oeqa.runtime.decorator.package import OEHasPackage
> +import threading
> +import time
>
>  class WestonTest(OERuntimeTestCase):
>
> @@ -17,3 +19,31 @@ class WestonTest(OERuntimeTestCase):
>  msg = ('Weston does not appear to be running %s' %
>self.target.run(self.tc.target_cmds['ps'])[1])
>  self.assertEqual(status, 0, msg=msg)
> +
> +def get_weston_command(self, cmd):
> +return 'export XDG_RUNTIME_DIR=/run/user/0; export DISPLAY=:0;
> %s' % cmd
> +
> +def run_weston_init(self):
> +self.target.run(self.get_weston_command('weston'))
> +
> +@OEHasPackage(['weston'])
> +def test_weston_info(self):
> +status, output =
> self.target.run(self.get_weston_command('weston-info'))
> +self.assertEqual(status, 0, msg='weston-info error: %s' % output)
> +
> +@OEHasPackage(['weston'])
> +def test_weston_can_initialize_new_wayland_compositor(self):
> +status, output = self.target.run('pidof weston-desktop-shell')
> +self.assertEqual(status, 0, msg='Retrieve existing
> weston-desktop-shell processes error: %s' % output)
> +existing_wl_processes = output.split(" ")
> +
> +weston_thread = threading.Thread(target=self.run_weston_init)
> +weston_thread.start()
> +time.sleep(5)
> +status, output = self.target.run('pidof weston-desktop-shell')
> +self.assertEqual(status, 0, msg='Retrieve existing and new
> weston-desktop-shell processes error: %s' % output)
> +wl_processes = output.split(" ")
> +new_wl_processes = [x for x in wl_processes if x not in
> existing_wl_processes]
> +self.assertTrue(new_wl_processes, msg='Check new
> weston-desktop-shell processes error: %s' % new_wl_processes)
> +for wl in new_wl_processes:
> +self.target.run('kill -9 %s' % wl)
> --
> 2.7.4
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137193): 
https://lists.openembedded.org/g/openembedded-core/message/137193
Mute This Topic: https://lists.openembedded.org/mt/72982654/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] oeqa/runtime/weston: Enhance weston tests

[Yeoh Ee Peng]

Existing weston test available make sure that a process
for weston-desktop-shell exist when image boot up.

Enhance weston tests by:
 - execute weston-info to make sure weston interface(s)
   are initialized
 - execute weston and make sure it can initialize a
   new wayland compositor

[YOCTO# 10690]

Signed-off-by: Yeoh Ee Peng 
---
 meta/lib/oeqa/runtime/cases/weston.py | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/meta/lib/oeqa/runtime/cases/weston.py 
b/meta/lib/oeqa/runtime/cases/weston.py
index f32599a..f79ed64 100644
--- a/meta/lib/oeqa/runtime/cases/weston.py
+++ b/meta/lib/oeqa/runtime/cases/weston.py
@@ -6,6 +6,8 @@ from oeqa.runtime.case import OERuntimeTestCase
 from oeqa.core.decorator.depends import OETestDepends
 from oeqa.core.decorator.data import skipIfNotFeature
 from oeqa.runtime.decorator.package import OEHasPackage
+import threading
+import time
 
 class WestonTest(OERuntimeTestCase):
 
@@ -17,3 +19,31 @@ class WestonTest(OERuntimeTestCase):
 msg = ('Weston does not appear to be running %s' %
   self.target.run(self.tc.target_cmds['ps'])[1])
 self.assertEqual(status, 0, msg=msg)
+
+def get_weston_command(self, cmd):
+return 'export XDG_RUNTIME_DIR=/run/user/0; export DISPLAY=:0; %s' % 
cmd
+
+def run_weston_init(self):
+self.target.run(self.get_weston_command('weston'))
+
+@OEHasPackage(['weston'])
+def test_weston_info(self):
+status, output = 
self.target.run(self.get_weston_command('weston-info'))
+self.assertEqual(status, 0, msg='weston-info error: %s' % output)
+
+@OEHasPackage(['weston'])
+def test_weston_can_initialize_new_wayland_compositor(self):
+status, output = self.target.run('pidof weston-desktop-shell')
+self.assertEqual(status, 0, msg='Retrieve existing 
weston-desktop-shell processes error: %s' % output)
+existing_wl_processes = output.split(" ")
+
+weston_thread = threading.Thread(target=self.run_weston_init)
+weston_thread.start()
+time.sleep(5)
+status, output = self.target.run('pidof weston-desktop-shell')
+self.assertEqual(status, 0, msg='Retrieve existing and new 
weston-desktop-shell processes error: %s' % output)
+wl_processes = output.split(" ")
+new_wl_processes = [x for x in wl_processes if x not in 
existing_wl_processes]
+self.assertTrue(new_wl_processes, msg='Check new weston-desktop-shell 
processes error: %s' % new_wl_processes)
+for wl in new_wl_processes:
+self.target.run('kill -9 %s' % wl)
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137192): 
https://lists.openembedded.org/g/openembedded-core/message/137192
Mute This Topic: https://lists.openembedded.org/mt/72982654/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-