[yocto] Error while using PSEUDO
Hello everyone,
I am trying to use pseudo due to I need to set my entire rootfs. I would like
to ask you some questions about how to use it, considering that it does not
seem to work. I am going to explain the process I have followed:
I enabled PSEUDO_DISABLED and PSEUDO_PREFIX at meta/conf/bitbake.conf:
export PSEUDO_DISABLED = "0"
export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"
Also, FILESYSTEM_PERMS_TABLE variable is pointing to my custom
fs-perms-cle.txt. It is declared at build/conf/local.conf. During the building
process, I receive constantly these kind of warning messages about "host
contamination":
WARNING: libgcc-7.3.0-r0 do_package_qa: QA Issue: libgcc: /libgcc-
dbg/usr/src/debug/libgcc/7.3.0-r0/gcc-7.3.0/build.powerpc-clepm-linux-gnuspe.powerpc-distro-linux-gnuspe/gcc/insn-constants.h
is owned by uid 1002, which is the same as the user running bitbake. This may
be due to host contamination [host-user-contaminated]
When it has finished, I check my rootfs or packages' image folder and
permissions are always set exactly equal as the user running bitbake. What is
going on? Have I missed something? Why my fs-perms.txt is ignored? I debugged
package.bbclass and parameters are parsed OK...
I have also tried to declare LD_PRELOAD variable, pointing directly to my host
libpseudo.so, but the result is the same:
LD_PRELOAD = "/usr/lib/x86_64-linux/pseudo/libpseudo.so"
LD_PREFIX = "/usr/"
Should I call fakeroot somewhere in the middle of the process?
It looks like an easy process, reading Yocto's manual but I think I have
forgotten something... I hope someone has had the same failure.
Thank you!
Best Regards,
Mario--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error while using PSEUDO
On 12/19/18 8:16 AM, madoga wrote:
> Hello everyone,
>
> I am trying to use pseudo due to I need to set my entire rootfs. I would like
> to
> ask you some questions about how to use it, considering that it does not seem
> to
> work. I am going to explain the process I have followed:
>
> I enabled PSEUDO_DISABLED and PSEUDO_PREFIX at meta/conf/bitbake.conf: / /
> /export PSEUDO_DISABLED = "0"//
> /
> /export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"/
The above is most certainly incorrect. Bitbake has all of these settings
themselves. Each recipe has it's own individual pseudo configuration and
database.
The errors below are likely due to incorrect settings above.
> Also, FILESYSTEM_PERMS_TABLE variable is pointing to my custom
> fs-perms-cle.txt.
> It is declared at build/conf/local.conf. During the building process, I
> receive
> constantly these kind of warning messages about "host contamination":
> /WARNING: libgcc-7.3.0-r0 do_package_qa: QA Issue: libgcc: /libgcc-
> dbg/usr/src/debug/libgcc/7.3.0-r0/gcc-7.3.0/build.powerpc-clepm-linux-gnuspe.powerpc-distro-linux-gnuspe/gcc/insn-constants.h
> is owned by uid 1002, which is the same as the user running bitbake. This may
> be
> due to host contamination [host-user-contaminated]/
>
> When it has finished, I check my rootfs or packages' image folder and
> permissions are always set exactly equal as the user running bitbake. What is
> going on? Have I missed something? Why my fs-perms.txt is ignored? I debugged
> package.bbclass and parameters are parsed OK...
Use the produced tarball from the build system, extract it with root permissions
on your system (or just view it in place) and the permissions will be correct.
You should not be attempting to use pseudo directly to manipulate things outside
of the build system. That isn't what it's intended for. Psuedo is to be used
with specific components to manage individual parts of the build system and
emulate the necessary filesystem parts and pieces that a regular user can not
typically access.
> I have also tried to declare LD_PRELOAD variable, pointing directly to my host
> libpseudo.so, but the result is the same:
> /LD_PRELOAD = "/usr/lib/x86_64-linux/pseudo/libpseudo.so"//
> /
> /LD_PREFIX = "/usr/"/
>
> Should I call fakeroot somewhere in the middle of the process?
> It looks like an easy process, reading Yocto's manual but I think I have
> forgotten something... I hope someone has had the same failure.
You do not call pseudo. The build system calls pseudo.
If you are defining custom tasks that attempt to manipulate components prior to
packaging, then you may have to declare the task as a 'fakeroot' task, this will
trigger the build system to load the necessary components and set it up in a
consistent way for that particular recipe's behavior.
--Mark
> Thank you!
> Best Regards,
> Mario
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-security] Open ssl version
Hi Team, I have set opnessl version in sumo but getting below errors. *PREFERRED_VERSION_openssl = "1.1.0i"* *Logs:* NOTE: Resolving any missing task queue dependencies NOTE: preferred version 1.1.0i of openssl not available (for item libssl) NOTE: versions of openssl available: 1.0.2p NOTE: preferred version 1.1.0i of openssl not available (for item openssl10) NOTE: versions of openssl available: 1.0.2p NOTE: preferred version 1.1.0i of openssl not available (for item openssl-conf) NOTE: versions of openssl available: 1.0.2p ERROR: Multiple versions of openssl are due to be built (/home/ubuntu/workspace/yocto/sources/poky/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb /home/ubuntu/workspace/yocto/sources/poky/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_openssl to select the correct version or don't depend on multiple versions. With Regards Vishwa On Fri, Dec 14, 2018 at 5:31 PM Burton, Ross wrote: > How did you set it? > > Also this isn't relevant to yocto-security, please move to yocto@. > > Ross > On Fri, 14 Dec 2018 at 11:53, Vishwanath Chandapur > wrote: > > > > Hi Ross, > > > > I tried to enable by using PREFERRED_VERSION. > > > > But getting these errors . > > > > NOTE: Resolving any missing task queue dependencies > > NOTE: preferred version 1.0.% of openssl not available (for item openssl) > > NOTE: versions of openssl available: 1.1.0i > > NOTE: preferred version 1.0.% of openssl-native not available (for item > openssl-native) > > NOTE: versions of openssl-native available: 1.1.0i > > NOTE: preferred version 1.0.% of nativesdk-openssl not available (for > item nativesdk-openssl) > > NOTE: versions of nativesdk-openssl available: 1.1.0i > > NOTE: preferred version 1.0.% of openssl not available (for item > openssl-dev) > > NOTE: versions of openssl available: 1.1.0i > > NOTE: preferred version 1.0.% of nativesdk-openssl not available (for > item nativesdk-openssl-dev) > > NOTE: versions of nativesdk-openssl available: 1.1.0i > > ERROR: Nothing RPROVIDES 'libssl > > >>> > > > > With Regards > > Vishwa > > > > > > On Thu, 13 Dec 2018 at 5:57 PM, Burton, Ross > wrote: > >> > >> Yes, Sumo has OpenSSL 1.1 but it isn't enabled by default because at > >> the time of release some important pieces of software had not yet > >> migrated. > >> > >> You can switch by using PREFERRED_VERSION. > >> > >> Ross > >> On Thu, 13 Dec 2018 at 12:13, Vishwanath Chandapur > wrote: > >> > > >> > Hi Team, > >> > > >> > Currently we are migrating to poly sumo version . > >> > But we have requirement to use 1.1.0 but poky is still supporting > 1.0.2 > >> > > >> > I would like know if latest OpenSSL available for future release . > >> > > >> > With Regard > >> > Vishwa > >> > ___ > >> > yocto-security mailing list > >> > yocto-secur...@yoctoproject.org > >> > https://lists.yoctoproject.org/listinfo/yocto-security > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] xrandr / xinput calibrator
Hy team, I tried to migrate from krogoth to sumo version of yocto project, to compile a custom OS for a custom board based on TI AM335x EVMSK Starter Kit. On this custom board there is a touchscreen panel (same like the AM335x EVMSK starter Kit) whitch worked fine with krogoth version. When I migrated to sumo version, while the OS boot the touchscreen work fine, but when the screen display to log the user and when it display the mouse, the touschreen panel is completely locked. I think that this append during the boot of the OS : Xrandr is called and try to do something to configure/set the touschscreen panel. But xrandr return the following message : polycaptil-machine-am335x-evmsk login: Size 1024x768 not found in available mode (screen resolution is 480x272) Later xinput_calibrator pring this message : Error: No calibratable devices found. But when I log to the user session (with putty) and I execute xrandr -listmonitors I get : xrandr: Failed to get size of gamma for output default Monitors: 1 0: +default 480/127x272/72+0+0 default It means that touschscreen panel is recognized with the right resolution but somewhere it's not correctly defined in the OS. I exported 0 in DISPLAY environnement variable and tried to use xininput_calibrator but without success. What can I do to solve this problem ? I don't know if I need to configure something when I compile the OS with yocto, or, if the configuration need to be done when the OS is booted and user is logged in ? I don't understand, because, I have not this problem (touschscreen panel locked and unusable) with krogoth version. Thank's to taking your time to read my problem and to trying to help me to solve it. STANISAVLJEVIC Nikola -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
