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
