Hello,
you can customize QB_OPT_APPEND by removing options you don't want, e.g.
QB_OPT_APPEND_remove = "-device usb-tablet"
and add your own after.
But maybe a lazy operator in the original conf file would be more suitable.
On Sat, 19 Jun 2021 at 06:41, Mike Frampton wrote:
> Greetings
Hello,
I currently used yocto warrior and I encounter an issue during packaging of
recipes.
I would like to embed some source package (to be able to run coverage on
target) , this work without issues and places the source of the package in
${ROOTFS}/usr/src/debug, but when I 'devtool modify' a
It it can help to understand, I rechecked the full content of source packages
and glib-2.0 / networkamanager are not ok like I said earlire.
There are not empty but they seem to contain only build generated files (for
example glib/glibconfig.h which, in the glib source repository, is
Hello, I dug further into yocto classes and I think I found what is going on.
All seems to come from the fact that gcc debug-prefix-map and macro-prefix-map
options are statically defined in bitbake.conf to
>
> DEBUG_PREFIX_MAP ?=
>
Hello, instead of creating a new variable (don't sure of its possible
usefulness), you can use BBMASK or review dependencies between your layer
PS: I did a similar answer on your stackoverflow question.
On Tue, 29 Jun 2021 at 01:29, Jonas Vautherin
wrote:
> I was thinking about my issue
Hello, some news about this issue.
Tim pointed me to the docker and the reason why crops container have some
UID:GID manipulation: [see
there](https://github.com/crops/extsdk-container/blob/master/usersetup.py).
I used an ubuntu 20.04 VM to setup a build without docker and I fall into the
Yes I do, I build under docker (ubuntu 20.04), I didn't mention that in my
original post , sorry. Do you think it is related to my issue ?
On Tue, Nov 15, 2022 at 09:06 PM, Tim Orling wrote:
>
> Are you building with a docker/podman container?
>
> On Tue, Nov 15, 2022 at 9:24
Hello list,
Doesn't ring a bell to anybody ? Even the slightest clue will help me to
continue to track down this weird behavior , nobody have ever problem of
files/directories rights during image generation ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
A ticket has been open for backporting the fix:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14971
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58644): https://lists.yoctoproject.org/g/yocto/message/58644
Mute This Topic:
Hello, I'm currently migrating our system from warrior to dunfell and I have an
issue on fitImage support for aarch64 architecture. We use KERNEL_IMAGETYPE =
"fitImage" and INITRAMFS_IMAGE_BUNDLE = "1" in our configuration and the kernel
do_deploy steps failed on not finding the initramfs file:
On Thu, Nov 3, 2022 at 11:38 PM, Zoran wrote:
>
> >>> - for imageType in ${KERNEL_IMAGETYPES} ; do
> >>> + for imageType in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
>
> Interesting... What is the difference between variables
> ${KERNEL_IMAGETYPES} and ${KERNEL_IMAGETYPE_FOR_MAKE} ?
>
In my setup I
Hello list,
I currently migrate our project from warrior to dunfell and we experience
some issues during the image generation step.
We have a custom IMAGE_FSTYPES to meet our need and in one of our custom
steps is to copy the rootfs (populated during yocto do_rootfs step) into a
custom dir and
Hello,
I dig up this thread to mention that the problem is still in kirkstone but was
fixed in langdale and greater.
I have done some dissection and found that the 3 following commits have fixed
it:
-
13 matches
Mail list logo
