Date   

[meta-selinux][PATCH 1/3] selinux-python: add RDEPENDES on audit-python

Yi Zhao
 

Add RDEPENDS on audit-python for selinux-python-semanage.

Fixes:
$ semanage fcontext -a -t user_home_t "/web(/.*)?"
Traceback (most recent call last):
File "/usr/sbin/semanage", line 975, in <module>
do_parser()
File "/usr/sbin/semanage", line 947, in do_parser
args.func(args)
File "/usr/sbin/semanage", line 329, in handleFcontext
OBJECT.add(args.file_spec, args.type, args.ftype, args.range, args.seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2485, in add
self.__add(target, type, ftype, serange, seuser)
File "/usr/lib/python3.9/site-packages/seobject.py", line 2481, in __add
self.mylog.log_change("resrc=fcontext op=add %s ftype=%s tcontext=%s:%s:%s:%s"
% (audit.audit_encode_nv_string("tglob", target, 0), ftype_to_audit[ftype],)
NameError: name 'audit' is not defined

Signed-off-by: Yi Zhao <yi.zhao@...>
---
recipes-security/selinux/selinux-python_3.2.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-security/selinux/selinux-python_3.2.bb b/recipes-security/selinux/selinux-python_3.2.bb
index a954676..d130900 100644
--- a/recipes-security/selinux/selinux-python_3.2.bb
+++ b/recipes-security/selinux/selinux-python_3.2.bb
@@ -50,6 +50,7 @@ RDEPENDS:${BPN}-semanage += "\
python3-xml \
python3-misc \
libselinux-python \
+ audit-python \
${BPN} \
"
RDEPENDS:${BPN}-sepolicy += "\
--
2.25.1


[meta-realtime][PATCH] schedtool-dl: add branch and protocol in SRC_URI

Chen Qi
 

Add branch and prototol to avoid do_fetch warnings.

Signed-off-by: Chen Qi <Qi.Chen@...>
---
recipes-tools/schedtool-dl/schedtool-dl.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-tools/schedtool-dl/schedtool-dl.bb b/recipes-tools/schedtool-dl/schedtool-dl.bb
index 59e3b32..c8f5d1e 100644
--- a/recipes-tools/schedtool-dl/schedtool-dl.bb
+++ b/recipes-tools/schedtool-dl/schedtool-dl.bb
@@ -3,7 +3,7 @@ SECTION = "devel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=dc1f51f7ca94aebffb9b3663d82873ec"

-SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=git \
+SRC_URI = "git://github.com/jlelli/schedtool-dl.git;protocol=https;branch=master \
file://0001-schedtool-dl-add-flags-to-parameters-of-sched_setattr.patch \
"
SRCREV = "3ffb479929c31cbae09de08f94f58b8f0f061d91"
--
2.33.0


Re: Touchscreen not working if keyboard or mouse plugged in

Khem Raj
 

On Tue, Dec 7, 2021 at 2:07 PM Greg Wilson-Lindberg
<gwilson@...> wrote:

We are building yocto Zeus for the Raspberrypi 4. We are using a touchscreen on the system, and it works just fine. But if a keyboard or mouse is plugged in when the system boots then the touchscreen is disabled.



I am wondering if there is a configuration somewhere that can be set to allow both the touchscreen and an external keyboard at the same time?

I wonder if its some overlap in device tree overlays


I’m sorry if this is the wrong forum to ask this, please point me in the right direction if not.
perhaps you can open a github issue here
https://github.com/agherzan/meta-raspberrypi/issues


Regards,

Greg Wilson-Lindberg




Touchscreen not working if keyboard or mouse plugged in

Greg Wilson-Lindberg
 

We are building yocto Zeus for the Raspberrypi 4. We are using a touchscreen on the system, and it works just fine. But if a keyboard or mouse is plugged in when the system boots then the touchscreen is disabled.

 

I am wondering if there is a configuration somewhere that can be set to allow both the touchscreen and an external keyboard at the same time?

 

I’m sorry if this is the wrong forum to ask this, please point me in the right direction if not.

 

Regards,

Greg Wilson-Lindberg


Re: Help with Inclusive Language in OpenEmbedded/Yocto Project

Michael Opdenacker
 

Hi Jon,

On 12/7/21 2:01 AM, Jon Mason wrote:
This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.

Definitely interested. I had already started contributing to
https://wiki.yoctoproject.org/wiki/Inclusive_language. Count me in.
Thanks
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Is there any recipe for #frr

Khem Raj
 

check

https://layers.openembedded.org/layerindex/branch/master/recipes/

if its not there then perhaps no one published it yet.

On Mon, Dec 6, 2021 at 11:24 PM <mousavy.system2005@...> wrote:

Hi
There is an old discussion regarding this in this link:
https://lists.frrouting.org/pipermail/frog/2019-January/000445.html
But I can't find any updated one. Is there an updated recipe to build FRR?
Thanks


Re: ls command

Khem Raj
 

On Tue, Dec 7, 2021 at 1:45 AM <msabood2014@...> wrote:

Hi Guys i am new in YOCTO project. i have build images before and the images were included the "ls" and "clear" and all busybox commands. i do not know what happend now the image does not have anymore the "ls" or "clear" and all that commands and also there is a folder named && in the root directory ? What to do ?
Sorry if my question is stupid but i am just a new in Yocto and linux
try to see if /bin/ls exists. if its not there then maybe its deleted
somehow. best is to flash a new rootfs


Yocto Project Status WW49`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M1 is due to build this week
  • YP 3.4.1 is likely to be released this week
  • There were some changes to the yocto-check-layer script to verify more of the contents of README files which has led to improvements in a number of layer README files.
  • The Yocto Project Summit and OpenEmbedded Developer virtual meetings last week seemed successful, thanks to the organizers and presenters for their hard work and presentations and everyone who attended to make it a success.
  • We have continued to audit a number of the patches in OE-Core with the removal of quite a number of obsolete patches and a number being submitted to the appropriate upstreams. This will result in an improvement to the quality of the core layer and make general maintenance easier going forward. Any help, particularly from those with knowledge of specific areas or upstreams would be most welcome.
  • We continue to see a reduction in the number of patches in the “Pending” state. Many thanks to everyone who has taken the time to review patch status and handle accordingly, particularly where they were accepted upstream. This will significantly benefit the project in the long term.
  • Intermittent issues continue to rise and help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • SWAT handling of autobuilder issues has sadly not been functioning correctly for the last couple of weeks with a large backlog of untriaged issues.

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 build date 2021/12/06
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.12 is released
  • YP 3.4.1 is out of QA.
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Setting BUILDNAME to a string broke in 3.1.12

Steve Sakoman
 

On Tue, Dec 7, 2021 at 12:21 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi

On Tue, Dec 7, 2021 at 1:34 AM Richard Purdie
<richard.purdie@...> wrote:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.
confirmed by commenting out the echo above that that "solves the
issue", so it's in fact this code that is now wrongfully triggered.
I think Richard was suggesting that you add
REPRODUCIBLE_TIMESTAMP_ROOTFS to "" to your local.conf.

I did so and confirmed that /etc/version now has BUILDNAME for its
contents as expected.

Richard is correct that the patch was setting
REPRODUCIBLE_TIMESTAMP_ROOTFS incidentally. This part of Mark's patch
seems to be the cause:

-inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') ==
'1', 'reproducible_build_simple', '')}
+inherit reproducible_build_simple

And reproducible_build_simple does:

BUILD_REPRODUCIBLE_BINARIES = "1"

export PYTHONHASHSEED = "0"
export PERL_HASH_SEED = "0"
export SOURCE_DATE_EPOCH ??= "1520598896"

REPRODUCIBLE_TIMESTAMP_ROOTFS ??= "1520598896"

So it is now overwriting what you've set in local.conf for
BUILD_REPRODUCIBLE_BINARIES. And if you look at your rootfs, you'll
probably see that all of the files are dated March 2019.

Master branch has restructured the code, but retained this behavior.

I'm not sure what the right answer is for dealing with the BUILDNAME
issue. Richard and Mark understand the reproducible build code far
better than I, perhaps they can offer an opinion on what to do here.

Steve


Re: [meta-rockchip][PATCH] README: Add intstructions to add patch template

Trevor Woerner
 

On Tue 2021-11-30 @ 06:27:53 PM, Khem Raj wrote:
Signed-off-by: Khem Raj <raj.khem@...>
---
README | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
Applied to meta-rockchip master branch. Thanks!


Re: Setting BUILDNAME to a string broke in 3.1.12

Henrik Riomar
 

Hi

On Tue, Dec 7, 2021 at 1:34 AM Richard Purdie
<richard.purdie@...> wrote:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.
confirmed by commenting out the echo above that that "solves the
issue", so it's in fact this code that is now wrongfully triggered.

/ Henrik


ls command

msabood2014@...
 

Hi Guys i am new in YOCTO project. i have build images before and the images were included the "ls" and "clear" and all busybox commands. i do not know what happend now the image does not have anymore the "ls" or "clear" and all that commands and also there is a folder named && in the root directory ? What to do ?
Sorry if my question is stupid but i am just a new in Yocto and linux


Re: How to log inside a recipe #yocto

tomzy
 

This is not something I do a lot but from what I know, you should be able
to use `bbnote` expresions etc inside the functions like `do_install` or
`do_compile` only if you inherit the `logging` bbclass
https://git.yoctoproject.org/poky/tree/meta/classes/logging.bbclass within
your recipes.

Regards
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com


Re: How to log inside a recipe #yocto

SAM
 

Thanks a lot. That works perfectly, but do you know how to use the log commands inside the recipe? It seems they work inside functions only (`do_install` e.g.)


Is there any recipe for #frr

SAM
 

Hi
There is an old discussion regarding this in this link:
https://lists.frrouting.org/pipermail/frog/2019-January/000445.html
But I can't find any updated one. Is there an updated recipe to build FRR? 
Thanks


Re: How to log inside a recipe #yocto

tomzy
 

Hi

To get a value of some variable added in recipe it is best to use bitbake
with `-e` flag which should print the whole environment, then one can just
use `grep` to search for given variable. Let say we have recipe `example.bb`
and need to know the value of `A_VAR` - with bitbake you can find it with

`bitbake -e example | grep ^A_VAR`

Regards
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com


How to log inside a recipe #yocto

SAM
 

Hi
There is a variable (or what ever it's called) inside a recipe. I want to know its value.
I've used `bbnote "something"` but this gives a parse error.
How to properly log?


Help with Inclusive Language in OpenEmbedded/Yocto Project

Jon Mason
 

This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.

Thanks,
Jon


Re: Setting BUILDNAME to a string broke in 3.1.12

Richard Purdie
 

On Mon, 2021-12-06 at 14:27 -1000, Steve Sakoman wrote:
On Mon, Dec 6, 2021 at 6:40 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.
After doing a bit of bisecting it appears that this commit is the culprit:

reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking
https://git.yoctoproject.org/poky/commit/?h=dunfell&id=0d6ebaf8ff3232248ebf0e859cd09aefaee54a8a

Since this was cherry-picked from master to fix some reproducibililty
errors I suspected that the issue might also exist in the master
branch.

A quick test with:

BUILD_REPRODUCIBLE_BINARIES = "0"
BUILDNAME = "my custom name"

added to local.conf confirmed that /etc/version was indeed
"20180309123456" instead of the expected "my custom name"

I'm out of time to work on this today, but perhaps Richard might have
some ideas on how to address this.
rootfs-postcommands.bbclass says:

# Perform any additional adjustments needed to make rootf binary reproducible
rootfs_reproducible () {
if [ "${REPRODUCIBLE_TIMESTAMP_ROOTFS}" != "" ]; then
# Convert UTC into %4Y%2m%2d%2H%2M%2S
sformatted=`date -u -d @${REPRODUCIBLE_TIMESTAMP_ROOTFS} +%4Y%2m%2d%2H%2M%2S`
echo $sformatted > ${IMAGE_ROOTFS}/etc/version
bbnote "rootfs_reproducible: set /etc/version to $sformatted"

if [ -d ${IMAGE_ROOTFS}${sysconfdir}/gconf ]; then
find ${IMAGE_ROOTFS}${sysconfdir}/gconf -name '%gconf.xml' -print0 | xargs -0r \
sed -i -e 's@\bmtime="[0-9][0-9]*"@mtime="'${REPRODUCIBLE_TIMESTAMP_ROOTFS}'"@g'
fi
fi
}

so I'd try setting REPRODUCIBLE_TIMESTAMP_ROOTFS to "". I suspect the change
above started setting that to some value incidentally.

Cheers,

Richard


Re: Setting BUILDNAME to a string broke in 3.1.12

Steve Sakoman
 

On Mon, Dec 6, 2021 at 6:40 AM Henrik Riomar <henrik.riomar@...> wrote:

Hi,

We set the BUILDNAME (via local.conf) variable to the output of "git
describe --long --always" so this info ends up in /etc/version instead
of a date. (i.e to know the exact source version of the code
deployed on a target)

This has worked fine for us up until 3.1.12, but now we just get a
date (201803...) in /etc/version.
After doing a bit of bisecting it appears that this commit is the culprit:

reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking
https://git.yoctoproject.org/poky/commit/?h=dunfell&id=0d6ebaf8ff3232248ebf0e859cd09aefaee54a8a

Since this was cherry-picked from master to fix some reproducibililty
errors I suspected that the issue might also exist in the master
branch.

A quick test with:

BUILD_REPRODUCIBLE_BINARIES = "0"
BUILDNAME = "my custom name"

added to local.conf confirmed that /etc/version was indeed
"20180309123456" instead of the expected "my custom name"

I'm out of time to work on this today, but perhaps Richard might have
some ideas on how to address this.

Steve




Note that since switching to Dunfell we were forced to set
BUILD_REPRODUCIBLE_BINARIES to 0, so the build system would not "mess
up" /etc/version, but not even that helps now.

What's the official way to get something more useful than a date (in
the long past) in /etc/version?

Thanks,
Henrik


2341 - 2360 of 57807