Re: [yocto] Linker error undefined reference to `_rtld_global_ro'

[Robert Varga]

Thank you very much for your response.

> 
> it seems static apps with glibc compiled with PIE related.
> 

I'm afraid I didn't understand (as I am new to yocto and try to understand it). 
Did you mean, the following statement in my-image.bb file generates the static 
apps which is not a good approach?
SDKIMAGE_FEATURES_append = " staticdev-pkgs"

I introduced this statement because I got linking errors when compiling/linking 
using the SDK complaining about missing libs just like ...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
 cannot find -lpthread
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
 cannot find -ldl
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
 cannot find -lstdc++
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
 cannot find -lm
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
 cannot find -lc
collect2: error: ld returned 1 exit status
makefile:128: recipe for target 'arm' failed
make: *** [arm] Error 1

When using this statement (SDKIMAGE_FEATURES_append = " staticdev-pkgs") I can 
see in /opt/mydistro/1.0.0/sysroots/usr/lib many *.a files which are not 
present without this statement. But I am not sure if this statement is correct? 
Maybe there is another approach for including the missing libs?

And what do you mean with "PIE related"? Are you thinking of an Raspberri PI?

> 
> Can you verfiy if you get same issue with aarch64 or mips ?

Also I would like to verify, but do not know how to setup for aarch64 or mips. 
Can you provide a short example?

Thank you for your support.

--

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

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

[yocto] meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

[Mans Zigher]

Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

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

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

Re: [yocto] meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

[Mans Zigher]

I have debugged cooker.py and everything looks good it produces a list
of the bbappend files that matches the expected result so something is
screwing it up when the recipe is baked since I can see that the order
is wrong when dumping the environment for the virtual/kernel.

BR

Den tis 14 juli 2020 kl 11:21 skrev zigext :
>
> Hi,
>
> I am using thud for my distro and I have two bbappend for my kernel I
> need to make sure that meta-layer1 is parsed before meta-layer2 to get
> the patches applied in the right order. So the patches in meta-layer2
> need to be applied after meta-layer1 patches have been applied. I have
> adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
> has 1110 based on "A larger value for the BBFILE_PRIORITY variable
> results in a higher precedence." but whatever I do I am still getting
> the wrong order and do_patch is failing. Any pointers to what I am
> doing wrong? I must be doing something wrong that is preventing the
> BBFILE_PRIORITY in my layer.conf to have an effect. Running
> "bitbake-layers show-layers" shows the expected output but when
> running the do_patch it is wrong and when dumping the env using
> "bitbake -e virtual/kernel" it is clear the order is wrong.
>
> BR
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

[Mans Zigher]

I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of  SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?

BR

Den tis 14 juli 2020 kl 13:29 skrev zigext :
>
> I have debugged cooker.py and everything looks good it produces a list
> of the bbappend files that matches the expected result so something is
> screwing it up when the recipe is baked since I can see that the order
> is wrong when dumping the environment for the virtual/kernel.
>
> BR
>
> Den tis 14 juli 2020 kl 11:21 skrev zigext :
> >
> > Hi,
> >
> > I am using thud for my distro and I have two bbappend for my kernel I
> > need to make sure that meta-layer1 is parsed before meta-layer2 to get
> > the patches applied in the right order. So the patches in meta-layer2
> > need to be applied after meta-layer1 patches have been applied. I have
> > adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
> > has 1110 based on "A larger value for the BBFILE_PRIORITY variable
> > results in a higher precedence." but whatever I do I am still getting
> > the wrong order and do_patch is failing. Any pointers to what I am
> > doing wrong? I must be doing something wrong that is preventing the
> > BBFILE_PRIORITY in my layer.conf to have an effect. Running
> > "bitbake-layers show-layers" shows the expected output but when
> > running the do_patch it is wrong and when dumping the env using
> > "bitbake -e virtual/kernel" it is clear the order is wrong.
> >
> > BR
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

[Mikko Rapeli]

Hi,

On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
> I figured it out the problem was that in meta-layer1 we had
> SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
> apparently will always be added to the end of  SRC_URI list and
> thereby the meta-layer2 patches will be applied first. Is it possible
> to get machine specific patches applied first?

You can try with SRC_URI_prepend_machine1.

Cheers,

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

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

Re: [yocto] meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

[Mans Zigher]

Thanks why I did not think of that. Anyway it works so thanks again.

BR

Den tis 14 juli 2020 kl 14:12 skrev :
>
> Hi,
>
> On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
> > I figured it out the problem was that in meta-layer1 we had
> > SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
> > apparently will always be added to the end of  SRC_URI list and
> > thereby the meta-layer2 patches will be applied first. Is it possible
> > to get machine specific patches applied first?
>
> You can try with SRC_URI_prepend_machine1.
>
> Cheers,
>
> -Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [yocto] Stable Warrior branch

[Adrian Bunk]

On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
> Hello,
> 
> The Warrior branch of Poky has had its last official dot release. It
> will be moving to Community support and EOL within 6 weeks if no one
> steps up.
> If someone is interested in taking on the responsibilities of
> maintaining the "Warrior" branch moving forward, please email this list.

I have an interest in keeping warrior branch alive in poky and meta-oe,
and I'll take this responsibility since noone else seems to be interested.

> Please look at the
> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
> be expected.

I have some ideas, but not yet a fixed plan how I will set this up.

> regards,
> Armin

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

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

[yocto] Query regarding the use of wic image during device upgrades

[Riz]

Hi,

I have been using wic image format lately to create partitioned image for my 
device.
I was wondering if wic image format can also be used during the device upgrade 
scenarios?

After using wic image, I have an impression that it is mainly used for 
initially writing the wic image to sdcard/eMMC but does not support all the 
thinkable use cases related to device upgrade.

As in, for example, can we selectively upgrade any single partition in the 
device using the wic image?
It would be really helpful if I can get some references or pointers on this 
topic.

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

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

[yocto] Yocto Project Status WW28'20

[Stephen Jolley]

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 16th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Aug. 4th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday July 14th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   A key autobuilder race has been identified as a race around the
bitbake lock file which will hopefully continue to reduce the number of
intermittent failures being seen. It potentially explains a number of the
open bugs. 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
*   We are struggling with maintainers for some key components of the
system/infrastructure such as devtool, wic, buildhistory and
patchwork/patchtest. If anyone can help in these areas please contact
Richard.
*   Another way to help the project is to help us with bugs that are
currently unassigned but ideally needed during 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   We're planning to migrate the project documentation from docbook to
sphinx. If you're interested/able to help with this please join the
discussion over on the docs mailing list.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2465 (last week 2485) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1269 (last week 1268)
*   Patches in the Pending State: 498 (39%) [last week 497 (39%)]

 

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...@gmail.com
 

 

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

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

[yocto] packages "shadow base-passwd" get removed at the end of do_rootfs

[Jochen Behnke]

Hello,

 

I have recipe "my-package" that

a) adds a user to the system (using "inherit useradd")

b) installs some bash-scripts

 

The my-package package is part of my image recipe and integrates without any problems.

The image also runs fine, no problems with the functionality of my-package so far.

 

But, when I try to install a newer (or the same) version of my-package on the target, rpm complains about missing dependencies.


The missing packages in the first place are

- shadow

- base-passwd

 

Querying the target rpm database (rpm -qa) confirms this, these packages are not installed (any more).

Having a look at log.do_rootfs revealed that the missing packages are installed during do_rootfs but are removed again at the end of the do_rootfs task.

Why is that?


 

I am using "thud" version of poky.

 

 

Thanks for any hint.

 

Jochen

 
 

 

 

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

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

Re: [yocto] Linker error undefined reference to `_rtld_global_ro'

[Khem Raj]

On 7/14/20 12:53 AM, Robert Varga wrote:
> Thank you very much for your response.
> 
> it seems static apps with glibc compiled with PIE related.
> 
> I'm afraid I didn't understand (as I am new to yocto and try to
> understand it). Did you mean, the following statement in my-image.bb
> file generates the static apps which is not a good approach?
> SDKIMAGE_FEATURES_append = " staticdev-pkgs"
> 
> I introduced this statement because I got linking errors when
> compiling/linking using the SDK complaining about missing libs just like ...
> /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
> cannot find -lpthread
> /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
> cannot find -ldl
> /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
> cannot find -lstdc++
> /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
> cannot find -lm
> /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld:
> cannot find -lc
> collect2: error: ld returned 1 exit status
> makefile:128: recipe for target 'arm' failed
> make: *** [arm] Error 1
> 
> When using this statement (SDKIMAGE_FEATURES_append = " staticdev-pkgs")
> I can see in /opt/mydistro/1.0.0/sysroots/usr/lib many *.a files which
> are not present without this statement. But I am not sure if this
> statement is correct? Maybe there is another approach for including the
> missing libs?
> 
> And what do you mean with "PIE related"? Are you thinking of an
> Raspberri PI?
> 
> Can you verfiy if you get same issue with aarch64 or mips ?
> 
> Also I would like to verify, but do not know how to setup for aarch64 or
> mips. Can you provide a short example?
> 
> Thank you for your support.

build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato

and install this SDK and repeat your experiment.

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

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

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

[Scott Murray]

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"
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-targeted"

Any ideas?

Thanks,

Scott


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

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

[yocto] [yocto-autobuilder2] builders.py: At the end of trigger builds use rm rather than clobber to clean up

[Steve Sakoman]

Since clobber is crossing two file systems in this case the worker
can delete the files faster than it can move them

Also fixes a occasional race that results in build failures

Signed-off-by: Steve Sakoman 
---
 builders.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/builders.py b/builders.py
index 13bfe18..778989b 100644
--- a/builders.py
+++ b/builders.py
@@ -377,9 +377,9 @@ def create_parent_builder_factory(buildername, waitname):
 
 
 factory.addStep(steps.ShellCommand(
-command=[clob, 
util.Interpolate("{}/%(prop:buildername)s-%(prop:buildnumber)s".format(config.sharedrepodir))],
+command=["rm", "-fr", 
util.Interpolate("{}/%(prop:buildername)s-%(prop:buildnumber)s".format(config.sharedrepodir))],
 haltOnFailure=True,
-name="Clobber shared repo dir"))
+name="Remove shared repo dir"))
 
 return factory
 
-- 
2.17.1

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

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

Re: [yocto] [meta-security][master|dunfell][PATCH 1/2] cryptsetup-tpm-incubator: RPROVIDES cryptsetup and cryptsetup-dev

[akuster]

On 7/13/20 9:00 PM, Jeremy Puhlman wrote:
> From: Jeremy Puhlman 
>
> Without this we get weird conflict when you include dev packages:
> rror: Transaction check error:
>   file /usr/include/libcryptsetup.h conflicts between attempted installs of
> cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
> lib32-cryptsetup-dev-2.3.2-r0.1.i586
>   file /usr/lib64/libcryptsetup.so conflicts between attempted installs of
> cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
> cryptsetup-dev-2.3.2-r0.1.corei7_64
>   file /usr/lib64/pkgconfig/libcryptsetup.pc conflicts between attempted
> installs of cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
> cryptsetup-dev-2.3.2-r0.1.corei7_64
>   file /usr/lib/libcryptsetup.so conflicts between attempted installs of
> lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
> lib32-cryptsetup-dev-2.3.2-r0.1.i586
>   file /usr/lib/pkgconfig/libcryptsetup.pc conflicts between attempted 
> installs
> of lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
> lib32-cryptsetup-dev-2.3.2-r0.1.i586

I plan on taking this for Dunfell. Master no long compiles do to core
package updates.

not sure what I am going to do for Master yet.

thanks for the patch.
Armin
> Signed-off-by: Jeremy Puhlman 
> ---
>  .../cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb   | 5 
> +
>  1 file changed, 5 insertions(+)
>
> diff --git 
> a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
>  
> b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
> index b706d15..2617162 100644
> --- 
> a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
> +++ 
> b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
> @@ -36,7 +36,12 @@ FILES_${PN} += "${libdir}/tmpfiles.d"
>  RDEPENDS_${PN} += "lvm2 libdevmapper"
>  RRECOMMENDS_${PN} += "lvm2-udevrules"
>  
> +RPROVIDES_${PN} = "cryptsetup"
>  RREPLACES_${PN} = "cryptsetup"
>  RCONFLICTS_${PN}  ="cryptsetup"
>  
> +RPROVIDES_${PN}-dev = "cryptsetup-dev"
> +RREPLACES_${PN}-dev = "cryptsetup-dev"
> +RCONFLICTS_${PN}-dev  ="cryptsetup-dev"
> +
>  BBCLASSEXTEND = "native nativesdk"
>
> 

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

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

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

[akuster]

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 
> ---
>  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 \
>
> 

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

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

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

[akuster]

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 
> ---
>  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] = "8eb96a7680bfa9c8f6de55502c44"
>  SRC_URI[sha256sum] = 
> "c358b80a2ea77a9dda79dc2a056dae3acaf3a72fcb8481cfb1cd1f16746324b4"
>  
> -S = "${WORKDIR}/${PN}"
> +S = "${WORKDIR}/${BPN}"
>  
>  inherit features_check
>  
>
> 

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

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

[yocto] 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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49956): https://lists.yoctoproject.org/g/yocto/message/49956
Mute This Topic: https://lists.yoctoproject.org/mt/75515307/21656
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [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


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

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

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

[Josef Holzmayr-Khosh Amoz]

Howdy!

Am Mi., 15. Juli 2020 um 07:40 Uhr schrieb Soi, Sheng Leong
:
>
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49958): https://lists.yoctoproject.org/g/yocto/message/49958
Mute This Topic: https://lists.yoctoproject.org/mt/75515307/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-