Date   

Re: Linker error undefined reference to `_rtld_global_ro'

Khem Raj
 

On 7/15/20 7:36 AM, Robert Varga wrote:
Thank you for instructions...
build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato
After long attempts I finally managed to create an SDK with qemuarm64. However, I did not use the core-minimal-sato as suggested, but used the same setup as in my-image.bb (which is based on the core-image-full-cmdline).
With this new SDK I then did the same experiment and compiled the application, and it worked! There were no linker error messages.
Now the question for me is, why did it compile with qemuarm64, but not with my settings?
Is there anything else I can do to isolate the issue?
Thanks for your support so far.
Can you check if your glibc is compiled with --enable-static-pie ?
search for GLIBCPIE and its value, if its set to --enable-static-pie then disable it for arm with GLIBCPIE_arm = ""

and retry

--
Rob


[meta-dpdk] is there a plan to support newer dpdk?

Rick Liu
 

Hi,

From meta-dpdk.git, the latest dufell branch is using dpdk 19.11.2.
Is there a plan to support dpdk 20.0x? 
(and maybe using meason/ninja to build?)

Rick


Re: openssh_8.0p1 on zeus - sshd.service not starting #yocto

Zoran
 

From the source config file:
ExecStart=@SBINDIR@/sshd -D $OPTIONS
From your reply:
But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.
If you run the command: /usr/sbin/sshd -D -f /etc/ssh/sshd_config, I
bet it'll fail again!

So, I have no idea what -D option does mean (lazy to investigate),
seems that this was the main cause of the problem:
https://unix.stackexchange.com/questions/390224/openssh-server-start-failed-with-result-timeout

Please, read this link carefully.

Best Regards,
Zoran
_______

On Thu, Jul 16, 2020 at 5:53 PM <srijan.nandi@...> wrote:

Hello Zoran,

I started the service and then ran journalctl -u sshd.service -r -n 10

This is what I see:

sshd.service Failed with result 'timeout'
sshd.service: start operation timed out. Terminating.

But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

Thanks,
-=Srijan Nandi


Re: package management

Baabu Ms
 

Hello Mr Jonathan Carter
                                        
                                            I followed your guidelines and I created my own recipe. ( packagegroup-multiple.bb )
packagegroup-multiple.bb The recipe contains the following packages


DESCRIPTION = "Package Group for Multimedia"

inherit packagegroup

PROVIDES = "${PACKAGES}"
PACKAGES = "\
    packagegroup-multiple"

RDEPENDS_packagegroup-multiple = "\
    gstreamer1.0 \
    gstreamer1.0-meta-base \
    gstreamer1.0-meta-audio \
    gstreamer1.0-libav \
    gstreamer1.0-plugins-base \
    gstreamer1.0-plugins-good \
    gstreamer1.0-plugins-bad \
    gstreamer1.0-plugins-ugly \
    v4l-utils \
    alsa-lib \
    alsa-plugins \
    alsa-tools \
    alsa-utils \
    alsa-utils-scripts \
    pulseaudio-client-conf-sato \
    "

I am trying to build a single deb for gstreamer, alsa packages.
But I did not build successfully.
Of the 3982 tasks attempted for the first time, 3947 tasks were successfully completed.
After I rebuilt 3982 Tasks 3982 Tasks do not need to be re-executed, but I tried to install but could not get these packages on my hardware.
I missed any packages to include Point me to where I made a mistake.
                                                                                                                                           
Thanks
Babu


On Wed, Jul 8, 2020 at 5:34 PM Jonathan Carter <jcc@...> wrote:
There's a detailed guide on how to get started with Debian packaging here:

https://www.debian.org/doc/manuals/maint-guide/start.en.html

-Jonathan

On 2020/07/08 13:25, Baabu JOY wrote:
> please share the Document related deb files creating through source file
>
> AIM : i need to create single deb file using multiple different source
> files (ex; gstreamer ,ffmpeg,alsa theses 3 should be in one .deb file )
> i hope u understand
>
> babu
>
> On Wed, Jul 8, 2020 at 4:34 PM Jonathan Carter <jcc@...
> <mailto:jcc@...>> wrote:
>
>     Hey Baabu
>
>     On 2020/07/02 05:43, Baabu JOY wrote:
>     > hello sir ,
>     >                This is babu ,im from bangloure (INDIA) ,im working on
>     > YOCTO in  Exaleap semiconductor pvt ltd company , i seen ur package
>     > management videos .
>     > i need some more information about package management
>     > we are creating the customized os for my own board for that trying to
>     > install the package through apt-get.
>     > now example there 5 package for multimedia and 10 packages for
>     file system
>     > i need to install all 5 multimedia package at ones .
>     > **
>     > *apt-get install package1 package2 package3 package4 package5 already
>     > implemented
>     > *
>     > *but i need below requirement please help me sir
>     > *
>     > *apt-get install multimedia*
>
>     Sounds like you want to create a metapackage. You can do that by
>     creating an empty package that depends/recommends on the packages that
>     you want.
>
>     -Jonathan
>
>     --
>       ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
>       ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
>       ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
>       ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.
>

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Debian, the universal operating system.

--
Thanks & Regards 
Exaleap
Babu p


Re: openssh_8.0p1 on zeus - sshd.service not starting #yocto

srijan.nandi@...
 

Hello Zoran,

I started the service and then ran journalctl -u sshd.service -r -n 10

This is what I see:

sshd.service Failed with result 'timeout'
sshd.service: start operation timed out. Terminating.

But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

Thanks,
-=Srijan Nandi


Re: openssh_8.0p1 on zeus - sshd.service not starting #yocto

Zoran
 

On my BBB board (as test vehicle), the following is true:

root@arm:~# uname -a
Linux arm 5.7.6 #1 SMP Tue Jun 30 16:46:05 CEST 2020 armv7l GNU/Linux
root@arm:~# lshw -short
H/W path Device Class Description
========================================
system TI AM335x BeagleBone Black
/0 bus Motherboard
/0/0 processor cpu
/0/1 processor idle-states
/0/2 memory 491MiB System memory
/1 eth0 network Ethernet interface
root@arm:~# which systemctl
/bin/systemctl
root@arm:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
Active: active (running) since Thu 2020-07-16 12:21:59 UTC; 2h 33min ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 435 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 765 (sshd)
Memory: 2.1M
CGroup: /system.slice/ssh.service
└─765 /usr/sbin/sshd -D

Jul 16 12:00:13 arm systemd[1]: Starting OpenBSD Secure Shell server...
Jul 16 12:21:59 arm sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 16 12:21:59 arm sshd[765]: Server listening on :: port 22.
Jul 16 12:21:59 arm systemd[1]: Started OpenBSD Secure Shell server.
root@arm:~#

Although I am not running YOCTO there, you can see that I have systemd
present, and that my sshd server is running.

You should give us more info using: $ journalctl -u sshd.service -r -n 1

Zoran
_______

On Thu, Jul 16, 2020 at 4:01 PM <srijan.nandi@...> wrote:

I am facing an issue with openssh_8.0p1 on zeus...systemd is not able to start sshd.service. I am using the following sshd.service file.

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshdgenkeys.service
Wants=sshdgenkeys.service

[Service]
Type=forking
PIDFile=@localstatedir@/run/sshd.pid
EnvironmentFile=-@SYSCONFDIR@/default/sshd
ExecStart=@SBINDIR@/sshd -D $OPTIONS
ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/run/sshd
ExecStartPre=/bin/chmod -R 755 /var/run/sshd
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target


Has anyone else faced a similar issue.


How to configure scheduler to SCHED_FIFO

sdw@...
 

In Yocto Warrior, it appears that the default scheduler configuration is SCHED_NORMAL. We are trying to do some time-critical I/O, and it seems like we may be missing some data. I'd like to increase the thread priority for our data acquisition, but am not sure how to do so.
Is it possible to reconfigure the kernel to use SCHED_FIFO or some other "real-time" scheduler? If so, how?
And what are the risks of changing the scheduler configuration?

Scott D. Whitney


openssh_8.0p1 on zeus - sshd.service not starting #yocto

srijan.nandi@...
 

I am facing an issue with openssh_8.0p1 on zeus...systemd is not able to start sshd.service. I am using the following sshd.service file. 
 
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshdgenkeys.service
Wants=sshdgenkeys.service
 
[Service]
Type=forking
PIDFile=@localstatedir@/run/sshd.pid
EnvironmentFile=-@SYSCONFDIR@/default/sshd
ExecStart=@SBINDIR@/sshd -D $OPTIONS
ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/run/sshd
ExecStartPre=/bin/chmod -R 755 /var/run/sshd
KillMode=process
Restart=on-failure
RestartSec=42s
 
[Install]
WantedBy=multi-user.target
 
 
Has anyone else faced a similar issue.


mongodb issue - missing systemd service and conf files #yocto

srijan.nandi@...
 

Hello Everyone,

I have installed mongodb on zeus. It seems the mogod.service and the mongod.conf files are missing. Can someone tell me where I can find these or maybe point me to some documentation where I can make these files using .bbappend. 

Thanks,
-=Srijan Nandi


Re: How to completely uninstall a pre-installed package in Yocto #linux #yocto

srijan.nandi@...
 

This is what I did. I ran the following:

bitbake <image> -e |grep -v ^# |grep "^DISTRO_FEATURES=\|^IMAGE_FEATURES="

Found out the DISTRO_FEATURES and IMAGE_FEATURES. Thne used DISTRO_FEATURES_remove in the local.conf to remove the features that I do not need. Hope this helps.

-=Srijan Nandi


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Yi Zhao
 


On 7/16/20 11:27 AM, Yi Zhao wrote:

On 7/15/20 6:38 PM, Scott Murray wrote:
On Wed, 15 Jul 2020, Yi Zhao wrote:

On 7/15/20 12:19 AM, Scott Murray wrote:
On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
    If we still keep two versions of refpolicy, it is difficult to maintain
    two huge local patchsets. So drop this version and only keep the git
    version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd.  That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration.  My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"
Ah, poky is missing "pam", I somehow missed that when I checked
previously.  I can get logged in when I add it and rebuild.  It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this.  Would you be okay with a patch that
does so?

Thanks. It makes sense. I can send a patch later or you can also do it.



If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.
Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.


You can install auditd into the rootfs and startup the daemon to let the denials messages write to audit.log rather than print to the console.


//Yi



For this issue, there is a discussion in http://oss.tresys.com/pipermail/refpolicy/2017-September/009865.html

Actually I saw lots of map denials on /etc/passwd or /etc/group for various commands. I'm not sure if we should allow them all via files_map_etc_files(domain) or dontaudit them ...


//Yi


Thanks,

Scott


    


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Yi Zhao
 

On 7/15/20 6:38 PM, Scott Murray wrote:
On Wed, 15 Jul 2020, Yi Zhao wrote:

On 7/15/20 12:19 AM, Scott Murray wrote:
On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain
two huge local patchsets. So drop this version and only keep the git
version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"
Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"
Ah, poky is missing "pam", I somehow missed that when I checked
previously. I can get logged in when I add it and rebuild. It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this. Would you be okay with a patch that
does so?
Thanks. It makes sense. I can send a patch later or you can also do it.



If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.
Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.
For this issue, there is a discussion in http://oss.tresys.com/pipermail/refpolicy/2017-September/009865.html

Actually I saw lots of map denials on /etc/passwd or /etc/group for various commands. I'm not sure if we should allow them all via files_map_etc_files(domain) or dontaudit them ...


//Yi


Thanks,

Scott


Re: Linker error undefined reference to `_rtld_global_ro'

Robert Varga
 

Thank you for instructions...
 
build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato
After long attempts I finally managed to create an SDK with qemuarm64. However, I did not use the core-minimal-sato as suggested, but used the same setup as in my-image.bb (which is based on the core-image-full-cmdline). 
With this new SDK I then did the same experiment and compiled the application, and it worked! There were no linker error messages.
Now the question for me is, why did it compile with qemuarm64, but not with my settings? 
Is there anything else I can do to isolate the issue?
Thanks for your support so far.
 
-- 

Rob


simplest way to disable all shared state cache for a build?

Robert P. J. Day
 

what is the simplest way to disable any use of sstate for a new build?
i see bitbake has a "--no-setscene" option that would appear to do that:

Do not run any setscene tasks. sstate will be ignored
and everything needed, built.

i've also seen some solutions that involve setting to empty strings
various variables like SSTATE_DIR, SSTATE_MIRRORS and so on. so if all
i want is to make sure everything is fetched, configured and built with
no use of sstate cache whatsoever, is "--no-setscene" the way to go?

rday

p.s. is this mentioned anywhere in the bitbake or a YP manual? seems
like this would be useful information for rigorous testing purposes.


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Scott Murray
 

On Wed, 15 Jul 2020, Yi Zhao wrote:


On 7/15/20 12:19 AM, Scott Murray wrote:
On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain
two huge local patchsets. So drop this version and only keep the git
version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"
Ah, poky is missing "pam", I somehow missed that when I checked
previously. I can get logged in when I add it and rebuild. It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this. Would you be okay with a patch that
does so?

If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.
Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.

Thanks,

Scott


Re: How to completely uninstall a pre-installed package in Yocto #linux #yocto

Josef Holzmayr
 

Howdy!

Am Mi., 15. Juli 2020 um 07:40 Uhr schrieb Soi, Sheng Leong
<sheng.leong.soi@...>:

The question is how to completely uninstall the pre-installed package in Yocto. Thanks

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.
In contrast to a general purpose distribution where you have little
control over the default set, there is no need to install anything you
do not want. So the correct solution is: do not install that package.

Even moreso, removing it later might be impossible if the image
doesn't have package management enabled.

Greetz


Re: [meta-selinux][PATCH 0/4] refpolicy: update to 20200229+git

Yi Zhao
 

On 7/15/20 12:19 AM, Scott Murray wrote:
On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain two huge local patchsets. So drop this version and only keep the git version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.
[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"


If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.


//Yi


PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-targeted"

Any ideas?

Thanks,

Scott


How to completely uninstall a pre-installed package in Yocto #linux #yocto

Soi, Sheng Leong
 

Hi,

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.

 


The question is how to completely uninstall the pre-installed package in Yocto. Thanks

FYI, I am new in building and compiling Yocto image.

 

 


Re: [meta-security][PATCH] ccs-tools:Fix build error when enable multilib.

Armin Kuster
 



On 7/6/20 10:30 PM, zhengruoqin wrote:
ERROR: lib32-ccs-tools-1.8.4-r0 do_install: oe_runmake failed
ERROR: lib32-ccs-tools-1.8.4-r0 do_install: Execution of
'/build-armv8/tmp/work/armv7ahf-neon-mllib32-linux-gnueabi/lib32-ccs-tools/1.8.4-r0/temp/run.do_install.22368'
failed with exit code 1:
make: *** No rule to make target 'install'.  Stop.
WARNING: exit code 1 from a shell command.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...>
---
 recipes-mac/ccs-tools/ccs-tools_1.8.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
merged.
Thanks

diff --git a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
index 2e37c0b..79af6a5 100644
--- a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
+++ b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
@@ -13,7 +13,7 @@ SRC_URI = "http://osdn.dl.sourceforge.jp/tomoyo/49693/${BPN}-${PV}-${DS}.tar.gz"
 SRC_URI[md5sum] = "eeee8eb96a7680bfa9c8f6de55502c44"
 SRC_URI[sha256sum] = "c358b80a2ea77a9dda79dc2a056dae3acaf3a72fcb8481cfb1cd1f16746324b4"
 
-S = "${WORKDIR}/${PN}"
+S = "${WORKDIR}/${BPN}"
 
 inherit features_check
 


    


Re: [meta-security][PATCH] bastille: Deleted redundant inherit to fix error when enable multilib.

Armin Kuster
 

merged

On 7/10/20 12:04 AM, zhengruoqin wrote:

There is no need to inherit module-base. Because this inherit will stop
bastille to build to lib32-bastille.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...>
---
 recipes-security/bastille/bastille_3.2.1.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/recipes-security/bastille/bastille_3.2.1.bb b/recipes-security/bastille/bastille_3.2.1.bb
index e9accb5..0290cae 100644
--- a/recipes-security/bastille/bastille_3.2.1.bb
+++ b/recipes-security/bastille/bastille_3.2.1.bb
@@ -9,8 +9,6 @@ DEPENDS = "virtual/kernel"
 RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long perl-module-text-wrap lib-perl perl-module-file-path perl-module-mime-base64 perl-module-file-find perl-module-errno perl-module-file-glob perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english perl-module-exporter perl-module-cwd libcurses-perl coreutils"
 FILES_${PN} += "/run/lock/subsys/bastille"
 
-inherit module-base
-
 SRC_URI = "http://sourceforge.net/projects/bastille-linux/files/bastille-linux/3.2.1/Bastille-3.2.1.tar.bz2 \
            file://AccountPermission.pm \
            file://FileContent.pm \