Re: [yocto] Empty source package when using devtool
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: - https://git.openembedded.org/openembedded-core/commit/?h=langdale=cbd6144a9769d21371ae0fe04db2adc05f6eed02 - https://git.openembedded.org/openembedded-core/commit/?h=langdale=c39b5020b8705d17e3745c41e38d0f99a1ac94cf - https://git.openembedded.org/openembedded-core/commit/?h=langdale=591cbe7140f01470b5799bc51e5b23f58bf95ffa WIth these 3 commits backported in kirkstone, I managed to having the source packages correctly populated with or without devtool activated on the components. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61876): https://lists.yoctoproject.org/g/yocto/message/61876 Mute This Topic: https://lists.yoctoproject.org/mt/83622035/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Ownership issue during do_image
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
exact same problem.
But finally, I found that a workaround by creating and using another working
directory inside my image creation command (though I clearly don't know why
this work and the former way don't, despite it worked with yocto warrior)
Before that, I have a working directory that was created in the bbclass :
```
SQSHDIR = "${S}/sqshimg/${MACHINE}"
do_image_tapos_sqshimg[dirs] += "${SQSHDIR}"
do_image_tapos_sqshimg[cleandirs] += "${SQSHDIR}"
do_image_tapos_sqshimg[recrdeptask] += "do_deploy"
IMAGE_CMD_tapos-sqshimg() {
install -d ${SQSHDIR}
```
I simply replaced the creation command by:
```
IMAGE_CMD_tapos-sqshimg() {
SQSHDIR_WORKDIR=$(mktemp -d)
```
and voilà !
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58810): https://lists.yoctoproject.org/g/yocto/message/58810
Mute This Topic: https://lists.yoctoproject.org/mt/94706311/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #dunfell
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: https://lists.yoctoproject.org/mt/94774777/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Ownership issue during do_image
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 AM Frederic Martinsons < > frederic.martins...@gmail.com> wrote: > > > 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. View/Reply Online (#58575): https://lists.yoctoproject.org/g/yocto/message/58575 Mute This Topic: https://lists.yoctoproject.org/mt/94706311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Ownership issue during do_image
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. View/Reply Online (#58572): https://lists.yoctoproject.org/g/yocto/message/58572 Mute This Topic: https://lists.yoctoproject.org/mt/94706311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #dunfell
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 have:
* KERNEL_IMAGETYPES=fitImage (coming from KERNEL_IMAGETYPE of my machine
configuration)
* KERNEL_IMAGETYPE_FOR_MAKE=Image (used only internally by kernel.bbclass and
setting to Image because of [this
line](https://github.com/openembedded/openembedded-core/blob/dunfell/meta/classes/kernel-fitimage.bbclass#L29)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58486): https://lists.yoctoproject.org/g/yocto/message/58486
Mute This Topic: https://lists.yoctoproject.org/mt/94774777/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] #dunfell
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: ``` | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/serial/usb_wwan.ko | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/serial/option.ko | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/class/ | lib/modules/4.19.255-rt113-sigfox/kernel/drivers/usb/class/cdc-wdm.ko | lib/modules/4.19.255-rt113-sigfox/modules.order | lib/modules/4.19.255-rt113-sigfox/modules.builtin | install: cannot stat 'arch/arm64/boot/Image.initramfs': No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Execution of '/home/fmartinsons/TAPOS_build_for_dunfell/build-tapos/tmp/work/a3700-tapos-linux/linux-sbs/4.19.255+gitAUTOINC+5c7ccbe1aa-r4.17.1.1/temp/run.do_deploy.1460182' failed with exit code 1 ``` Doing some more research, I found that the problem came from this change https://git.openembedded.org/openembedded-core/commit/?id=526bdd88ccd758204452579333ba188e29270bde , I found a commit introduced in kirkstone that fix my issue (at least the part which revert the previous commit): https://git.openembedded.org/openembedded-core/commit/?id=10a4a132e87e835726bf5da81a60f6f509b90765 Can somebody know why the commit was not back-ported in dunfell ? Regards. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58476): https://lists.yoctoproject.org/g/yocto/message/58476 Mute This Topic: https://lists.yoctoproject.org/mt/94774777/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Ownership issue during do_image
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 act on it (reorganizing tree and making a squash file
system).
I'm experiencing an issue on file ownership preservation that I didn't have
in warrior.
We use rsync to copy the rootfs tree to another location (via multiple
option, including the -a one which preserve ownership) and during that
step, I see a lot of:
```
rsync: chown "" failed: Operation not permitted (1)
```
The files and directories are nevertheless copied (but of course.
To investigate further I do a devshell and reproduce the issue via a simple
'cp -a' (which also preserve ownership of files) and see the same king of
ownership preservation problems:
```
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
ll ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping
-rwxr-xr-x 1 root root 22680 Mar 9 2018
${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping*
root@SGX-CMP-776
:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
cp -a
${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/bin/arping .
cp: failed to preserve ownership for './arping': Operation not permitted
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
ll arping
-rwx-- 1 1000 1000 22680 Mar 9 2018 arping*
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
id
uid=0(root) gid=0(root) groups=0(root)
```
During devshell'ed session, the rootfs populated by do_rootfs is seen as
root user (while the real user is me with uid 1000) , I guess this is due
to the fact that the images step is run under pseudo and fakes user/group.
What I can't understand is why pseudo (or something else) doesn't do the
same with my file copy ?
```
root@SGX-CMP-776:${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/tapos-image-1.0#
ll ${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/
total 72
drwxr-xr-x 17 root root 4096 Nov 1 05:38 ./
drwxr-xr-x 12 1000 1000 4096 Nov 1 05:38 ../
drwxr-xr-x 2 root root 4096 Mar 9 2018 bin/
drwxr-xr-x 2 root root 4096 Mar 9 2018 boot/
drwxr-xr-x 2 root root 4096 Mar 9 2018 dev/
drwxr-xr-x 38 root root 4096 Nov 1 05:38 etc/
lrwxrwxrwx 1 root root8 Nov 1 05:38 home -> /rw/home
drwxr-xr-x 8 root root 4096 Mar 9 2018 lib/
lrwxrwxrwx 1 root root 19 Mar 9 2018 linuxrc -> /bin/busybox.nosuid
drwxr-xr-x 2 root root 4096 Mar 9 2018 media/
drwxr-xr-x 2 root root 4096 Mar 9 2018 mnt/
dr-xr-xr-x 2 root root 4096 Mar 9 2018 proc/
drwxr-xr-x 2 root root 4096 Mar 9 2018 run/
drwxr-xr-x 5 root root 4096 Nov 1 05:38 .rw_skeleton/
drwxr-xr-x 2 root root 4096 Mar 9 2018 sbin/
dr-xr-xr-x 2 root root 4096 Mar 9 2018 sys/
-rw-r--r-- 1 root root 149 Mar 9 2018 .tapos.manifest
drwxrwxrwt 2 root root 4096 Mar 9 2018 tmp/
drwxr-xr-x 10 root root 4096 Mar 9 2018 usr/
drwxr-xr-x 7 root root 4096 Nov 1 05:38 var/
fmartinsons@SGX-CMP-776:~$ ll
${TMPDIR}/work/aimb231-tapos-linux/tapos-image/1.0-r0/rootfs/
total 72
drwxr-xr-x 17 fmartinsons fmartinsons 4096 nov. 1 06:38 ./
drwxr-xr-x 12 fmartinsons fmartinsons 4096 nov. 1 06:38 ../
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 bin/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 boot/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 dev/
drwxr-xr-x 38 fmartinsons fmartinsons 4096 nov. 1 06:38 etc/
lrwxrwxrwx 1 fmartinsons fmartinsons8 nov. 1 06:38 home -> /rw/home
drwxr-xr-x 8 fmartinsons fmartinsons 4096 mars 9 2018 lib/
lrwxrwxrwx 1 fmartinsons fmartinsons 19 mars 9 2018 linuxrc ->
/bin/busybox.nosuid
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 media/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 mnt/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 proc/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 run/
drwxr-xr-x 5 fmartinsons fmartinsons 4096 nov. 1 06:38 .rw_skeleton/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 sbin/
drwxr-xr-x 2 fmartinsons fmartinsons 4096 mars 9 2018 sys/
-rw-r--r-- 1 fmartinsons fmartinsons 149 mars 9 2018 .tapos.manifest
drwxr-xr-t 2 fmartinsons fmartinsons 4096 mars 9 2018 tmp/
drwxr-xr-x 10 fmartinsons fmartinsons 4096 mars 9 2018 usr/
drwxr-xr-x 7 fmartinsons fmartinsons 4096 nov. 1 06:38 var/
fmartinsons@SGX-CMP-776:~$ id
uid=1000(fmartinsons) gid=1000(fmartinsons) groups=1000(fmartinsons)
```
Am I missing something about pseudo usage ? And if so, why did these copy
operations work perfectly within warrior branch ?
Has anyone already experienced this
Re: [yocto] Would COMPATIBLE_IMAGE make sense?
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 described here [1], and discovered the > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use > to stop recipes from being built for machines (/hosts) with which the > recipes are not compatible". And so I wondered if it would make sense to > add COMPATIBLE_IMAGE, for a similar purpose. > > Let me explain my issue: I define different images in different layers > (say `first-project-image` and `second-project-image`), and in each of > those layers I create `.bbappends` to configure some packages. Typically > `hostapd` is used by both images, but with a different config file. > > The thing is that when I run `bitbake first-project-image`, because > `second-project-image` is part of my bblayers.conf, then the > hostapd_%.bbappend from `second-project-image` is used and may have an > impact on `first-project-image`, which I don't want. I really want this > bbappend to only affect the image `second-project-image`. > > One way I can see to deal with that is to realize that > `first-project-image` and `second-project-image` are two different > projects, and build them from two different BUILDDIRs. The thing I don't > like here is that all the packages are therefore downloaded and built > twice, which seems like a loss of time and space. > > That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend > of `first-project-image`, I would set "COMPATIBLE_IMAGE = > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE = > 'second-project-image'". So that I could still share a BUILDDIR between > different projects. > > How bad of an idea is that? > > Thanks in advance, > Jonas > > [1]: https://stackoverflow.com/questions/68167244/image-specific-layers > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54001): https://lists.yoctoproject.org/g/yocto/message/54001 Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Empty source package when using devtool
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 ?=
> "-fmacro-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
> \
> -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
> \
> -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> "
>
>
>
I'll took an example to try to be clearer. Let's say that I devtool modify the
glib-2.0 package. Without any configuration, sources will be extracted in
${BDIR}/workspace/sources/glib-2.0.
Build directory is set by externalsrc.bbclass to
${BDIR}/tmp/work/${arch}-${distro}/glib-2.0/${PN}/${EXTENDPE}${PV}-${PR}/${BPN}/${BPN}-${PV}
(the real path doesn't matter, what is matter is that B is not under devtool
spaces).
This lead to have pretty long relative path in gcc compilation line (sotheming
like -c ../../../../../../../../worspace/sources/glib-2.0/glib/gmain.c for
example). Hence the debug-prefix-map could not be appplied.
After the compilation stage, package.bbclass (via splitdebuginfo), there is an
extraction of sources path via dwarf format parsing. We ended up parsing
something like
- /workspace/sources/glib-2.0/glib/gmain.c
instead of
- /usr/src/debug/glib-2.0/1_2.58.3-r0.2/glib-2.58.3/glib/gmain.c
I patch externalsrc.bbclass to dynamically caculate correct debug-prefix-map
and prepend to DEBUG_PREFIX_MAP variable, I also patch the package.bbclass to
add a condition when EXTERNALSRC is defined to change the way the sources are
found and copied to packages-split/${pkg}-src.
I would greatly appreciate if there is a yocto guru around there to tell me
what he thinks about all of this (bug or wrong configuration ?) and if my
assumptions are correct (I assume this was a compiling/packaging problem
instead of a pure devtool one)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53936): https://lists.yoctoproject.org/g/yocto/message/53936
Mute This Topic: https://lists.yoctoproject.org/mt/83622035/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Appending an existing machine .conf file
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 Yocto,
>
> I'm interested in assigning custom config settings for machine type
> qemuarm.
>
> I tried a method suggested in this thread
> https://lists.yoctoproject.org/g/yocto/message/38359 by Ayoub Zaki, he
> suggested defining the following in local.conf
>
> > include conf/machine/${MACHINE}-extra.conf
>
> However, this doesn't work for me because quemuarm.conf in poky/meta
> **assigns** its variables, e.g.,
>
> > QB_OPT_APPEND = "-device VGA,edid=on"
> > QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
>
> So that if I define a value for this, it will be overwritten.
>
> Is there another method for achieving this? If not I could submit a
> patch to change poky's definitions to "??" assignments.
>
> Cheers,
> --Mike
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53917): https://lists.yoctoproject.org/g/yocto/message/53917
Mute This Topic: https://lists.yoctoproject.org/mt/83644679/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Empty source package when using devtool
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 glib/glibconfig.h. *in* ). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53908): https://lists.yoctoproject.org/g/yocto/message/53908 Mute This Topic: https://lists.yoctoproject.org/mt/83622035/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Empty source package when using devtool
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 recipe to work on , the
source package is totally empty.
First, I suspected that was my various recipe customization so I tried the same
method (devtool modify then packing it and look at content of -src package) for
more standard package, here are my results:
- glib-2.0 -> ok
- networkmanager -> ok
- dnsmasq -> empty source
- zlib -> empty source
I try to look at log.do_package but I didn't see any warning nor error there.
Since warrior is EOL, I tried a fresh poky on dunfell and hardknott, I got the
exact same results. Is anybody here have experienced this ? Is this bug or did
I miss some configuration ?
Thank you very much in advance for any help you can bring.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53907): https://lists.yoctoproject.org/g/yocto/message/53907
Mute This Topic: https://lists.yoctoproject.org/mt/83622035/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
