dreese has quit [Remote host closed the connection]
dreese has joined #yocto
dreese has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
dreese has joined #yocto
dreese has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
dreese has joined #yocto
rber|res has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
RobertBerger has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
camus has joined #yocto
sakoman has joined #yocto
kroon has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
dtometzki has joined #yocto
TundraMan has joined #yocto
marka has quit [Ping timeout: 250 seconds]
sakoman has quit [Quit: Leaving.]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
<moto-timo>
kanavin: so much ♥️ thank you for the patch bomb
<moto-timo>
Zero time to look
thomas_ has joined #yocto
mihai has joined #yocto
ThomasRoos has joined #yocto
rob_w has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<thomas_>
good morning
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
<RP>
rburton: reproducible failed with the new sstate/hashequiv versioning
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
ThomasRoos has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
vladest has quit [Quit: vladest]
vladest has joined #yocto
davidinux has joined #yocto
michalkotyla has quit [Quit: michalkotyla]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
michalkotyla has joined #yocto
kranzo has joined #yocto
florian_kc has joined #yocto
Schlumpf has joined #yocto
florian_kc has quit [Ping timeout: 250 seconds]
olani has joined #yocto
dev1990 has joined #yocto
<thomas_>
Whats the difference between += and _append? Why should _append be used in local.conf instead of += ?
<LetoThe2nd>
thomas_: rather :append by the way, there was a syntax change about a year ago.
<thomas_>
LetoThe2nd, yes, I've read about it in the mega manual. But why :append over += ?
<LetoThe2nd>
thomas_: += can be handy at times, but its more blunt because it also adds a space automatically. but both should do their respective duties. oh, and IIRC you can't use overrides on +=, but on :append
<thomas_>
Okay, I'm just wondering. I've got some Seminar Handout from Avnet in my hands, and they said rather use append than += in local.conf. But not the reason behind it :)
<LetoThe2nd>
thomas_: there might be deeper reasons too, but on the top level, :append is just way more flexible.
<qschulz>
thomas_: if you have a variable in a recipe with ?=, using += in local.conf will override the variable with the content of the += instead oaf adding it
<qschulz>
using :append allows to add the content of the += to the one in ?=
<qschulz>
add the conte of the :append*
<qschulz>
content*
<thomas_>
ahhhhhh, yes that makes sense qschulz :) thanks
<LetoThe2nd>
again what learned!
<qschulz>
thomas_: also, strive to have as little as possible in local.conf
<LetoThe2nd>
i will forget and relearn the next time qschulz talks about it, but hey, makes me feel good today.
<thomas_>
Its on slide 14 LetoThe2nd
<LetoThe2nd>
yeah, keep local.conf as KISS as possible.
ThomasRoos has joined #yocto
tnovotny has joined #yocto
<thomas_>
How does the Hands on lab work on tuesday? Do I need to prepare a local yocto instance beforehand?
<thomas_>
I've never heard about digital ocean
<qschulz>
thomas_: IIRC there will be cloud instances you'll have ssh access to
<thomas_>
Ah okay. I'll ask my boss if he give me the time to attend :)
davidinux has quit [Ping timeout: 260 seconds]
ecdhe has quit [Read error: Connection reset by peer]
davidinux has joined #yocto
eggman has quit [Quit: brb]
eggman has joined #yocto
tnovotny has quit [Quit: Leaving]
ecdhe has joined #yocto
<kanavin>
moto-timo, cheers. I think this brings oe-core entirely up to date (as of May 1st), save for some updates on hold for known issues.
Guest49 has joined #yocto
<kanavin>
e.g. setuptools :D
<Guest49>
Hi! "...using the old override syntax. Please convert this layer/metadata before ....newer bitbake". Is there a web page or something explaining how to convert?
<ptsneves>
does anybody have an idea why oe_runmake-task-compile() {} does not override for the kernel compile/
<T_UNIX[m]>
hi
<T_UNIX[m]>
ptsneves: have you had a look at the environment (`bitbake -e some-recipe`)?
<qschulz>
ptsneves: I've never seen oe_runmake-task-compile before.. what are you trying to achieve?
<T_UNIX[m]>
<thomas_> "Whats the difference between..." <- > Although the functions for both variables are nearly equivalent, best practices dictate using `IMAGE_FEATURES` from within a recipe and using `EXTRA_IMAGE_FEATURES` from within your `local.conf` file, which is found in the Build Directory.
<ptsneves>
i looked directly at the run.do_compile and it is not there. The task is also not triggered.
<ptsneves>
I am trying to manually log the output of make so as to create a bbwarn if a magic string comes up.
<ptsneves>
oe_runmake-task-kernel-compile() {
<ptsneves>
bbwarn "Capturing do compile"
<ptsneves>
oe_runmake_call "$@" | tee log || die "oe_runmake failed"
<ptsneves>
grep -qi GENSEED log && bbwarn "Generated a new seed"
<ptsneves>
}
<ptsneves>
something along the way
florian_kc has joined #yocto
<T_UNIX[m]>
could anybody tell me how I can have a look at a recipe's environment (`-e`) within the context of some image (especially a certain set of `IMAGE_FEATURES`)?
<qschulz>
T_UNIX[m]: cannot, recipes are sandboxed
<qschulz>
you can check what's the value of a variable in a recipe, but you cannot check the value of a variable in another recipe
Tyaku has joined #yocto
<T_UNIX[m]>
It appears that a recipe is not rebuild, even if I change its `PACKAGECONFIG` depending on its `IMAGE_FEATURES`.
<qschulz>
T_UNIX[m]: where do you set IMAGE_FEATURES?
<thomas_>
Thanks T_UNIX[m]
<kroon>
I wasn't aware that you can use overrides based on task. Where is that set ? And how do I then dump the environment for a specific recipe task ?
<qschulz>
kroon: you can but usually it's VAR:task-compile
<qschulz>
ptsneves: so I think it should just be oe_runmake:task-compile instead?
<qschulz>
also, use _ instead of : if you're on a release older than dunfell
<ptsneves>
seems my bookmark is out date. I am on dunfell
<qschulz>
if you are on dunfell or later, make sure to use the latest version of the release, and you'll have support for both _ and : override syntax
<ptsneves>
i did not know that the : syntax was backported to the dunfell brnach
<qschulz>
ptsneves: dunfell is a special case, we have docs both in the old website and in the newer one
<qschulz>
the docs for dunfell on the old website stops at 3.1.4 (included)
<qschulz>
there are patches being worked on to display a banner on the old website
<ptsneves>
the new docs look great. Would it be too much effort and put the release name (dunfell) in the version combo box?
<Tyaku>
Hi, Is there a way to debug "*** buffer overflow detected ***" on a release software built by bitbake recipe ? (for example to get the stack trace ?)
<qschulz>
ptsneves: I think that's doable, I've a patch somewhere for that but was waiting to fix a bigger change to send it
<ptsneves>
qschulz the oe_runmake:do_compile does not work either. It seems that for functions the override does not work
<qschulz>
ptsneves: I never suggested that
<ptsneves>
oops..did you mean oe_runmake:task-comple() {}?
<Tyaku>
ptsneves: When you speak about debug symbols, Do you speak about the CFLAG -g ? Because when I read the run.do_compile of my recipe, I see something like this: export CFLAGS=" -O2 -pipe -g ......
<qschulz>
ptsneves: yup
<qschulz>
and if that does not work, then oe_runmake_task-compile
<qschulz>
ptsneves: also, make sure you're actually overriding the correct task, because the kernel recipes usually have a few intermediate tasks before compile
<ptsneves>
tried both and nope. The task is do_compile so i am pretty sure of that(?)
<ptsneves>
i will just override for the whole recipe and be done with it :(
<qschulz>
ptsneves: not entirely sure that overrides are supported for shell functions which aren't tasks
<ptsneves>
yeah probably the case.
Schlumpf has quit [Quit: Client closed]
<ptsneves>
I think there is a workaround by treading the shell function as a variable, meaning not using the () but direct = assignment, but it is besides my current goal
Schlumpf has joined #yocto
<ykrons>
Hi all
Schlumpf has quit [Quit: Client closed]
Guest49 has quit [Quit: Client closed]
<ykrons>
I'm facing an issue to update a patch for a newer kernel. I think I have successfully used devshell and quilt in the past for that (on a zeus or maybe older version) and today with a dunfell kernel, it seems something has changed and quilt can't find patches. Is quilt still used or replaced ?
<qschulz>
ykrons: devtool should have everything you need to create patches and add them to the original recipe, so maybe try that
<qschulz>
but AFAIK, no, quilt is still used by default for patching
<ptsneves>
ykrons as qschulz says. It is much more work to do it manually in the devshell
<ykrons>
ok, I have tried first with devtool but I could not find my patches applied (it makes sense as they have to be updated ...) to have tried then with devshell to applied them manually ... will give a second try to devtool. Thanks
<ptsneves>
the patches applied can be seen by git log :)
<ptsneves>
it is that simple
Schlumpf has joined #yocto
<ykrons>
but current patch don't apply with the newer kernel so I guess have to reapply them manually
nemik has quit [Ping timeout: 250 seconds]
<ptsneves>
you can manually apply and then when the new patch is good you just commit it
nemik has joined #yocto
<ptsneves>
and git format-patch -n1 --full-index and you have a re-created patch
<qschulz>
git am my.patch; resolve conflicts; git am --continue
<qschulz>
and then there's a devtool command to create the patches and add them to the recipe
<qschulz>
something like devtool finish with an option or something
Schiller has joined #yocto
<ykrons>
Thanks. Should be ok now. I have already used devtool in the past but not to update patches.
nemik has quit [Ping timeout: 240 seconds]
<Schiller>
Hello there. I have a controller-node and a worker-node. When i start the controller-container check the IP and create the worker in the worker-container like this buildbot-worker create-worker -r --umask=0o22 yocto-worker <controller-IP> some_name pass they connect fine. But when i try to give my controller container a static IP the
<Schiller>
worker-container seems to hang an is not able to connect even tho in twisted.log he tries to connect to the specific IP which the controller-container has. Can someone explain this behaviour?
nemik has joined #yocto
<Tyaku>
If I want to apply INHIBIT_SYSROOT_STRIP = "1" only to one recipe, I have to put "INHIBIT_SYSROOT_STRIP_pn-myrecipename = "1"" in local.conf ?
<qschulz>
Tyaku: or add it directly to the recipe via a bbappend
kroon has quit [Quit: Leaving]
<T_UNIX[m]>
<qschulz> "T_UNIX: where do you set..." <- I set them within the image's recipe.
<qschulz>
but yes, if on old syntax _pn-myrecipenbame, if on new :pn-recupename
ThomasRoos has quit [Quit: Client closed]
<qschulz>
T_UNIX[m]: you cannot access IMAGE_FEATURES set in your image recipe from another recipe
<T_UNIX[m]>
And I check them wihtin i.e. qtbase
<qschulz>
an image recipe is a recipe, all limitations from package recipes apply
<qschulz>
T_UNIX[m]: what you want is DISTRO_FEATURES
<qschulz>
because it's set globally
<thomas_>
I have a function defined which is assigned to ROOTFS_POSTPROCESS_COMMAND (ROOTFS_POSTPROCESS_COMMAND += "tisdk_image_build; "). How I can force the bitbake to execute ROOTFS_POSTPROCESS_COMMAND?
<qschulz>
thomas_: it should be run by default IIRC
<thomas_>
I deleted the output of tisdk_image_build manually. So bitbake things this task is still up to date and do not execute it I guess. But calling bitbake -c do_rootfs does not work either
<thomas_>
*thinks
<T_UNIX[m]>
I want the same bounding set (systemd, etc.). That goes into my `distro.conf`. But I want one image to contain debug features while the other one shall not
<T_UNIX[m]>
one image shall then contain packages with some extra flags set, while the other image shall not
mvlad has joined #yocto
<T_UNIX[m]>
so I do not want to change DISTRO features. Kernel, Bootloader, Initmanager shall all stay the same.
<LetoThe2nd>
T_UNIX[m]: then you can append the distro. but the image cannot affect the things that go inside, just select.
<qschulz>
T_UNIX[m]: what you describe are two different distros in Yocto
<T_UNIX[m]>
Okay. So I need to build another distribution to have packages built differently?
<qschulz>
yup
<qschulz>
that's a "policy"
<qschulz>
(building debug features for all packages)
<LetoThe2nd>
T_UNIX[m]: in a nutshell, yes. but the debug distro can essentially be just "original distro plus one flag"
<qschulz>
so it is a responsibility of distros
<qschulz>
thomas_: checkl with bitbake -e that your function is actually in ROOTFS_POSTPROCESS_COMMAND
<thomas_>
ok
<T_UNIX[m]>
yeah, that's what I got wrong. In my head building debug images would alter the packages. An since there are debug-pkgs, I figured, that should work for other modifications as well.
<LetoThe2nd>
T_UNIX[m]: but thats what i meant by "can select". because the image can select those additional dbg packages, which are essentially the symbols.
<T_UNIX[m]>
So `IMAGE_FEATURES` is basically merelly a convenience (implicit selection) around `IMAGE_INSTALL`?
<T_UNIX[m]>
anyway. Thanks for the clearification 🙂
<LetoThe2nd>
T_UNIX[m]: look at the image.bbclass and see for yourself.
<qschulz>
T_UNIX[m]: IMAGE_INSTALL is for packages. IMAGE_FEATURES is for anything, you can have switches anywhere in code if one feature is in that variable or not
<qschulz>
allows to have multiple images with the same features by using IMAGE_FEATURES from a distro configuration file
<T_UNIX[m]>
qschulz: This simple view is what I had in mind. But I didn't know that `IMAGE_FEATURES` could basically only modify `FILES` so to say.
<qschulz>
T_UNIX[m]: ?
<Tyaku>
I try to put this 'INHIBIT_SYSROOT_STRIP:pn-cpc-daemon = "1"' in my local.conf then bitbake -c cleanall cpc-daemon and rebuild the target. But the generated executable is still stripped
<Tyaku>
/usr/bin/cpcd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=0de089ca21b39d94af966b912f009dd192f9a95a, for GNU/Linux 3.14.0, stripped
<qschulz>
Tyaku: Are you sure it's INHIBIT_SYSROOT_STRIP that you want?
<T_UNIX[m]>
qschulz: `IMAGE_FEATURES` shall only modify what (i.e. debug symbols) get's build, right? It shall _not_ modify how something is built.
<T_UNIX[m]>
i.e. `CFLAGS`, etc.
<T_UNIX[m]>
s/modify/affect/
<rburton>
IMAGE_FEATURES doesn't modify how anything is built
<kayterina[m]>
Hello, I get a "pickle protocol " error when running bitbake for anything. I have removed the tmp directory. I am running through docker if it is important : https://pastebin.com/q3eyriwZ
<thomas_>
qschulz, I checked with bitbake -e that the function is really in ROOTFS_POSTPROCESS_COMMAND
<thomas_>
its there
<qschulz>
thomas_: you can run bitbake -c do_rootfs -f to check if your function is run
<qschulz>
this will force the running of do_rootfs even if it already was run
<qschulz>
once you've made sure your function is executed, then you can go a bit deeper and try to understand why it's not been rerun even though it changed
<thomas_>
okay
pgowda_ has joined #yocto
prabhakarlad has joined #yocto
tomzy_0 has joined #yocto
Guest48 has joined #yocto
RobertBerger has joined #yocto
ptsneves has quit [Quit: Client closed]
<Guest48>
Hello, I am trying to build qemu with Yocto. I install all dependences, make a copy of poky from git, sourced oe-init-build-env and start bitbake firstly without any updates of local.conf, than I make a changes just up to your video. I still get the same error message:
<Guest48>
> ERROR: Failed to spawn fakeroot worker to run poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.14.bb:do_install: [Errno 32] Broken pipe
<Guest48>
> I don’t have any idea how I can solve it. I was trying to find solutions on internet but I didn’t.
<Guest48>
I use honister branch
<Guest48>
Debian 10 as host machine
<Guest48>
I was following the youtube video and yocto documentation
ptsneves has joined #yocto
Schlumpf has quit [Ping timeout: 252 seconds]
<qschulz>
ptsneves: just sent a patch for the branch names to be displayed in the dropdown menu on the docs, thanks for asking
<Guest48>
sorry I don't understand what you mean
<kranzo>
Guest48: what video are you talking about? qschulz did not reply to you btw :)
<Guest48>
I just want to make bitbake core-image-minimal and I still get an error with fakeroot
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
Schiller has quit [Quit: Client closed]
<ykrons>
ptsneves, qschulz : Thanks for your help. I finally get my first kernel patches updated ...
<ptsneves>
ykrons congrats
<ykrons>
Question: I have some kernel changes dispatched between patches (maybe 10) in the recipe and a forked kernel repository with maybe 50 commits. Is there any good reason not to move everything into the repo? I don't like to review modified patches. Diff of diff are breaking my brain and eyes
<qschulz>
ykrons: if you can push to the forked kernel repo, better push there
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
<thomas_>
I have a image-a.bb and a image-a-sdk.bb. Can I somehow add all IMAGE_INSTALL entities from image-a.bb automatically to IMAGE_INSTALL from image-a-sdk.bb ? Without defining a packagegroup which is included by both?
<thomas_>
Both images using the same machine configuration
<ptsneves>
thomas_ create an .inc file with the common stuff and include in both images
<ptsneves>
i call it the distributive property of includes :D
<ptsneves>
when you want a common C in recipe A and B then AC+BC = C(A+B) where C is the include and A and B are recipes including C
<thomas_>
Basically what I want is an "sdk"-image, which has all packages of the "production"-image plus all the dev dbg and static-dev stuff
<ptsneves>
by the way sdk image is not a target image and IMAGE_INSTALL is not valid there
<thomas_>
ptsneves, Yes thats clear. I was wondering if some IMAGE_INSTALL_iamge-a variable may exist
<ptsneves>
thomas_ do not understand your last comment
<thomas_>
To generate an SDK which should include a targetfs which should be equal as possible with my actual production image
Schiller has joined #yocto
<thomas_>
Because image -c do_populate_sdk is not supported from arago it seems
<ptsneves>
yeah it is not supported because they are doing something very creative. They are creating an image with host tools for the target?
<thomas_>
What you mean by hsot tools for the target?
<ptsneves>
i have no experience with TI layers, but this is not very yocto specific and i never worked with TI layers so I cannot help. The issue is they confuse image with SDK and they are not the same in yocto. I think you are in for a ride
<ptsneves>
IMAGE_INSTALL generates images for a target
<ptsneves>
SDK_INSTALL generates sdk packages for SDK_MACHINE
nemik has quit [Ping timeout: 250 seconds]
<thomas_>
Yeah I know - I sit between the chairs
<ptsneves>
:) i suggest you ask in the TI forums
nemik has joined #yocto
<thomas_>
:) Sure, Ive done that. But it will take weeks if I ever get an answer which redirects me either to yocto or arago "community"
<thomas_>
But thanks for the IMAGE_INSTALL and SDK_INSTALL definition. The problem is, I havn't understand the bigger picture of arago
<thomas_>
And I do know less about generating an SDK the normal yocto way to bridge that knowledge gap
<thomas_>
So sdk packages are normally just the cross-toolchains right?
<thomas_>
I'll go with that include solution.. :D
<ptsneves>
hey Tomas, sorry not always available. The deal is you have an SDK_MACHINE set (the machine your sdk is supposed to be deployed, normally x86-64) and the MACHINE which represents your target.
<ptsneves>
Your sdk contains cross toolchain and cross libraries. The goal being you can compile programs using your sdk, outside yocto.
<ptsneves>
what TI, has is some creation of their own and i don't understand it without deep diving in it, but that is work that is likely paid :)
<ptsneves>
qschulz do we have any page of Yocto consultants?
<qschulz>
ptsneves: first result on your favorite search engine with "yocto consultants" :)
kranzo has joined #yocto
<kranzo>
or did i misuderstand the question?
<ptsneves>
kranzo not at all. Perfect! I did not know of such page. The yocto project has a really nice communication
Schiller has quit [Quit: Client closed]
<thomas_>
ptsneves, thank you very much ;) I don't wanna blame anyone. I think software engineers at TI are also very busy and have limited time for customer support. Just the documentation about arago could a bit more...
kranzo has quit [Quit: Client closed]
kranzo has joined #yocto
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
ptsneves has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
<thomas_>
ptsneves, what about TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK ? Are packages that are added to that variables deployd either on MACHINE / SDK_MACHINE ?
Schiller has joined #yocto
zyga-mbp has joined #yocto
<kranzo>
just nativesdk- versions of them
<kranzo>
added them to get a working sdk but nor esdk wont build properly. :/
<LetoThe2nd>
zeddii: have you ever run into reproducible.py failing on a missing singletask.lock for a go-based recipe?
<thomas_>
kranzo, I just need a working SDK - i pray for it
<kranzo>
thomas_: ah my brain mixed your thread into my problem:D need another coffee
<thomas_>
I've added a package to TOOLCHAIN_TARGET_TASK. But it seems not to get deployed in the target rootfs. How do I find out why? I've checked with bitbake -e the content of TOOLCHAIN_TARGET_TASK and it shows up there.
<thomas_>
kranzo, im sorry :)
<kranzo>
did you enable BUILDHISTORY?
<thomas_>
yes, i have a buildhistory folder
<zeddii>
LetoThe2nd: I can't say that I have. strange that it is being packaged in one, or otherwise influencing the output. Is the recipe doing something 'strange' that might be capturing the transient lock file ?
<ptsneves>
thomas_ the variables you mention are used to build an SDK. YOu build an SDK with populate_sdk task.There are no rootfs for sdks
<thomas_>
ptsneves, How do I call the cross libraries of my SDK? I thought its the rootfs of the SDK
<ptsneves>
i think you do not need to do any fancy thing. the cross toolchain automatically sets the sysroot of your cross compilers to the location of your target libraries
<LetoThe2nd>
zeddii: what might be a strange thing? the only thing that i know of noteworthy that its cgo.
<thomas_>
In my world, an SDK consists of two parts. First, the toolchain I need to build against the target. And second I need all the libs/headers for that target
<kranzo>
thomas_: both will be in the sdk
<zeddii>
LetoThe2nd: There have been builds in the past that copied/captured files and / or checksum'd the source dir, and then incorporated that hash into the binaries. That could pick up a transient file and cause an issue like that. but if this is calling go/cgo directly in the recipe, and not using the packages scripts/Makefile, that definitely won't be happening here.
<kranzo>
you can check for installed files in the buildhistory folder
tomzy_0 has joined #yocto
<thomas_>
Okay lets say I have a package foobar, which is a library. I install foobar on my normal "production"-image. Now I want to create an app which depends on foobar. I need now an SDK which includes the foobar-lib and also the foobar-header at /usr/lib and /usr/include
<LetoThe2nd>
zeddii: hmmm that might be misworded then by me. the error specifically said that singletask.lock was missing. the reprodicible part is only that it is being searched for from reproducible.py
<zeddii>
aha. I see.
<thomas_>
And the folder, whereas the header and libray are placed in to build my app against it, I called that "rootfs" of the SDK. Because it has the same structure like the normal production-image
<thomas_>
Is that wrong?
<zeddii>
right, there should be no randomness there.
<GuestNew>
After updating to kirkstone, i got the issue during boot "module has no symbols (stripped?)" I'm not self confident with Yocto to understand what I have to configure fix that ? (I'm FPGA developer and i don't know many thing about linux drivers) any help ?
<thomas_>
ahh perfect. thank you kranzo !!! Now I can go from here and search for the reason why it doesnt show up :D
nemik has joined #yocto
hcg has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
ptsneves has quit [Quit: Client closed]
sakoman has joined #yocto
ptsneves has joined #yocto
Guest48 has quit [Quit: Client closed]
<thomas_>
holy shit! I think I've got it!!!! Lol - it took me nearly a full week! A SDK for my custom image based on arago!
nemik has quit [Ping timeout: 248 seconds]
<thomas_>
Big dopamin release in my brain!
nemik has joined #yocto
<Tyaku>
I found the function that cause my "buffer overflow" error !!! (But I don't really understand because how this function is implemented is not clearly explained). The code calls realpath(x, y) where x is a char * = "/dev/serial/by-id/usb-Silicon_Labs_J-Link_Pro_OB_000000123456-if00" (terminated by \0) and y is a 256 bytes buffer. After increasing the size of Y from 128 to 4096 I don't have buffer overflow,
<Tyaku>
but after the function execution y contains "/dev/ttyACM0".
sashko has quit [Ping timeout: 240 seconds]
<Tyaku>
So I think, internally this function do something like "memset()" on the entire size of the expected buffer [...]
<kranzo>
thomas_: gz
<kranzo>
my esdk is still not compiling because basehash changes and i'm relay confused why
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
GuestNew has quit [Quit: Client closed]
<LetoThe2nd>
armpit: sorry for misreading the date. my bad.
<Tyaku>
When I debug cpc-daemon (build with the yocto toolhchain) I don't have "buffer overflow". I filled the y parameter with caracter "0xaa", and I see that only the first bytes are changed by the function.
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<Tyaku>
But I think when bitbake build cpc-daemon, this function works differently
<Tyaku>
is it possible to see how is implemented "realpath()" ?
ptsneves has quit [Quit: Client closed]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<kranzo>
can someone give me a hint how i can track down basehash changes?
F_Adrian has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<kanavin>
RP, F_Adrian and I would like to talk about eSDK plans when you have a bit of time, would really appreciate your input.
Schiller has quit [Ping timeout: 252 seconds]
otavio has quit [Ping timeout: 250 seconds]
otavio has joined #yocto
<thomas_>
kranzo, i had the same issue: My root problem was the git auth stuff. Some recipes used git to read git hashes which failed when the user "root" did it
lexano has quit [Ping timeout: 246 seconds]
rber|res has quit [Ping timeout: 248 seconds]
RobertBerger has quit [Ping timeout: 248 seconds]
<thomas_>
This causes that by reevaluation from normal user the "task metadata" has been changed which resulted in changed basehashes
<kranzo>
seems clear but how did you find that? i'm stuck because i cant even check what is happaning
<thomas_>
Yocto printed a command which I used to track this down - I try to find it again
<kranzo>
ah sadly the output is empty all the time :/
tgamblin has quit [Ping timeout: 248 seconds]
<thomas_>
Sorry. In my case it even printed the variable that has been changed
tomzy_0 has quit [Quit: Client closed]
kranzo has quit [Quit: Client closed]
thomas_ has quit [Ping timeout: 248 seconds]
kranzo has joined #yocto
lexano has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
ptsneves has joined #yocto
Tyaku has quit [Quit: Lost terminal]
nemik has quit [Ping timeout: 260 seconds]
Schlumpf has quit [Quit: Client closed]
nemik has joined #yocto
hcg has quit [Quit: Client closed]
Schlumpf has joined #yocto
rber|res has joined #yocto
RobertBerger has joined #yocto
cmd has quit [Ping timeout: 240 seconds]
RobertBerger has quit [Remote host closed the connection]
rber|res has quit [Remote host closed the connection]
kranzo has quit [Quit: Client closed]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Schlumpf has quit [Quit: Client closed]
<rburton>
RP: so interestingly, fakeroot doesn't have the problem that pseudo does. "fakeroot git status" doesn't moan that the repo is owned by another user...
ilunev has joined #yocto
stanf has joined #yocto
stanf27 has joined #yocto
stanf has left #yocto [#yocto]
stanf27 has left #yocto [#yocto]
stanf has joined #yocto
<rburton>
oh, fakeroot changes ownership of files it reads too!
<rburton>
that's ... horrid
<rburton>
$ ls -l Makefile
<rburton>
$ fakeroot ls -l Makefile
<rburton>
-rw-rw-r-- 1 ross ross 108341 May 5 17:13 Makefile
<rburton>
-rw-rw-r-- 1 root root 108341 May 5 17:13 Makefile
<ptsneves>
Hey i am having randome mismatches with kernel module versions. There is a new flag CONFIG_GCC_PLUGIN_RANDSTRUCT enabled by default in newer kernels which enables randomization struct addresses. This randomization is based on a seed. In dunfell this seed is generated on the do_compile, copied to the work-shared CONFIG_GCC_PLUGIN_RANDSTRUCT by
<ptsneves>
kernel.bbclass:do_work_shared and then make-mod-scripts overwrites that value
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
florian has quit [Quit: Ex-Chat]
<ptsneves>
Here i show a prefunc of make-mod-scripts:do_configure and a postfunc printing the
<mario-goulart>
Hi. In scenarios where BBMULTICONFIG is set, is expected that events like BuildCompleted are fired multiple times?
nemik has joined #yocto
camus has quit [Ping timeout: 260 seconds]
JPEW has quit [Ping timeout: 246 seconds]
JPEW has joined #yocto
lexano has quit [Ping timeout: 256 seconds]
lexano has joined #yocto
mckoan is now known as mckoan|away
ptsneves has quit [Quit: Client closed]
stanf has quit [Quit: Client closed]
stanf has joined #yocto
bps has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
otavio has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
otavio has joined #yocto
otavio has quit [Ping timeout: 248 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
stanf has quit [Quit: Client closed]
otavio has joined #yocto
otavio has quit [Ping timeout: 248 seconds]
otavio has joined #yocto
<JPEW>
mario-goulart: yes
zyga-mbp has quit [Read error: Connection reset by peer]
zyga has joined #yocto
<mario-goulart>
JPEW: thanks!
bps has joined #yocto
bps has joined #yocto
florian_kc has joined #yocto
<sveinse>
Is there a way to mute the warning "Submodule included by ... refers to relative ssh reference git@github.com:user/repo.gi. References may fail if not absolute."? This way of specifying repo references is very common, encouraged even, by github and bitbucket, so many repos are littered with this subrepo references, leading to a storm of false positive warnings in the build logs.
<JPEW>
sveinse: That seems like a false positive on the warning to me
GillesM has quit [Remote host closed the connection]
<sveinse>
It seems its the syntax `git@github.com:user/repo.git` and the lack of `:/` in the url that triggers the warning
<sveinse>
The fix is to use the full (proper?) syntax `ssh:\\git@github.com/user/repo.git` but I'd argue that that format isn't that widely used in git urls.
<JPEW>
sveinse: Ya. I'm not sure what usage pattern fray was attempting to check for there; might wait to see if any insight is given
<JPEW>
Might be able to update the check if we know qhat a "bad" URL is supposed to be
mvlad has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<sveinse>
What does the error "An allarch packagegroup shouldn't depend on packages which are dynamically renamed (lksctp-tools to libsctp1)" mean? As in, what change do I need to make in the packagegroup? Rename rdep to libsctp1 as it sais in the error?
olani has quit [Remote host closed the connection]
<neverpanic>
sveinse: This message is to protect you, really. You seem to have what's called "debian renaming" enabled, where packages that only contain libraries are renamed to <libraryname><soversion>
<sveinse>
What I'm understanding from this is that I need to extract all the "dynamically renamed" packages into a separate tune specific packagegroups?
<neverpanic>
If you didn't have this warning and added a dependency, but then updated the library so that its soname (and thus generated package name) changes, the packagegroup wouldn't be rebuilt, and thus be broken.
<neverpanic>
Either that, or you just need to make the packagegroup not allarch. The overhead of doing the latter is probably negligible
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
mihai has quit [Quit: Leaving]
<RP>
kanavin: quite the series, thanks! :)
gsalazar_ has quit [Ping timeout: 248 seconds]
<kanavin>
RP: cheers :) and I prefer to not use the word 'bomb' for the time being.
<kanavin>
it had produced a completely green a-full too last night, I was glad enough to see that on my smartphone, that I actually jumped out of bed to hit git send-email, then fall back into bed
olani has joined #yocto
<kanavin>
work from home can mix up 'work' and 'home' like that
<RP>
kanavin: I was wondering about the timing! :)
<RP>
kanavin: it is nice to see some of the patch counts falling
<kanavin>
RP: yes, I have a (bad) habit of checking my a-fulls from my mobile. I wish buildbot had a 'blind mode' where you can't see builds in progress :)
GillesM has joined #yocto
GillesM has quit [Client Quit]
<kanavin>
only the final verdict!
<mcfrisk>
sveinse: saw that today too, and marked the package group tune specific as the poky side commit says
<kanavin>
RP: I'll try to carry on with upstreaming or otherwise streamlining the pending patches
<RP>
kanavin: I do tend to watch my builds too! :)
<RP>
kanavin: I'm still hoping we can see a chunk of libtool ones merge and the new gcc release cleans up a few there too
florian_kc has quit [Ping timeout: 260 seconds]
bps has joined #yocto
bps has joined #yocto
florian_kc has joined #yocto
Rolle6 has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<Rolle6>
I'll try to formulate my question though I am very new to Yocto. I have two "top-level" bb classes, one that builds the SDK, full image etc, and one that builds the initramfs (expressed as to .bb files). The initramfs bb file basically inherits from core-image. The initramfs needs to be used later when i build applications with the sdk (it will
<Rolle6>
be baked into a fitImage in a later stage when I have access to more dtsi files), so I I would like to distribute the initramfs with the SDK. I cannot just point to the bb file with TOOLCHAIN_TARGET_TASK (I assume as it has not install stage etc?) How can I include it in my SDK?
bps has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
rhowell has joined #yocto
<rhowell>
Is it possible to force change the BBFILE_PRIORITY of a single recipe in my layer? I have a do_install_append() that needs to be highest priority so I can override stuff. But my code is ending up in the middle of the final do_install() function. My layer priority is set to "6" and the other conflicting layer is set to "8". I have tried
<rhowell>
BBFILE_PRIORITY = "10" in the recipe itself, but the it doesn't seem to have an effect. is there a way to force set the priority for a single recipe or can I only set it at the layer level?
<sveinse>
I thought I had all allarch packagegroups under control, but then one in official meta-qt5 turns up in nativesdk-packagegroup-qt5-toolchain-host :( Apparently it does not help to bbappend in PACKAGE_ARCH = "${TUNE_PKGARCH}" either