nerdboy has quit [Remote host closed the connection]
nerdboy has joined #yocto
jtoomey has quit [Ping timeout: 264 seconds]
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
camus has joined #yocto
khem has quit []
ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
nerdboy has quit [Ping timeout: 240 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
wicki has quit [Ping timeout: 240 seconds]
nerdboy has quit [Remote host closed the connection]
emdevt has joined #yocto
nerdboy has joined #yocto
lexano has quit [Ping timeout: 255 seconds]
xmn has quit [Read error: Connection reset by peer]
Vonter has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
Vonter has joined #yocto
emdevt__ has joined #yocto
emdevt has quit [Ping timeout: 240 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
amitk has joined #yocto
ederibaucourt has quit [Ping timeout: 252 seconds]
lthadeus has joined #yocto
ederibaucourt has joined #yocto
Chaser has joined #yocto
lthadeus has quit [Ping timeout: 240 seconds]
lthadeus has joined #yocto
jmd has joined #yocto
emdevt__ has quit [Quit: Leaving]
Guest7 has joined #yocto
olani- has quit [Ping timeout: 276 seconds]
jmd has quit [Remote host closed the connection]
Chaser has quit [Ping timeout: 268 seconds]
alessioigor has joined #yocto
thomas_34 has joined #yocto
<thomas_34>
Good morning, a short question regarding .bbappend files: I know I can use bbappend files to overwrite existing variables in the "parent" recipe. But can I also introduce new variables in bbappend files? I have a problem that a new variable, which I set in a bbappend file does not show up when I do bitbake -e.
Chaser has joined #yocto
lthadeus has quit [Remote host closed the connection]
lthadeus has joined #yocto
amitk has quit [Quit: leaving]
goliath has joined #yocto
flom84 has joined #yocto
<yocton>
thomas_34: Yes, you can introduce new variables in bbappend files. Are you sure your .bbappend is read at all?
<thomas_34>
Yes, because it manipulates the git repo of the sources. Okay, thank you for that information. At least that is not an issue in my situation
rob_w has joined #yocto
brrm has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 240 seconds]
brrm has joined #yocto
mckoan|away is now known as mckoan
Vonter has joined #yocto
Kubu_work has joined #yocto
flom84 has quit [Ping timeout: 260 seconds]
vladest has quit [Ping timeout: 252 seconds]
<landgraf>
RP: hmmm. maybe fixed in meantime (or "fixed" by repopulating of sstate?). Should I resent patches?
frieder has joined #yocto
ptsneves has joined #yocto
mvlad has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
lthadeus has quit [Ping timeout: 268 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
vladest has joined #yocto
lthadeus has joined #yocto
leon-anavi has joined #yocto
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 256 seconds]
ptsneves has joined #yocto
goliath has quit [Ping timeout: 245 seconds]
ptsneves has quit [Ping timeout: 260 seconds]
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
landgraf: we probably need to retest
dvergatal has joined #yocto
leon-anavi has quit [Ping timeout: 260 seconds]
yannd has quit [Ping timeout: 268 seconds]
leon-anavi has joined #yocto
manuel_ has joined #yocto
mckoan has quit [Read error: Connection reset by peer]
<landgraf>
RP: And for this I have to resend patches with cover letter "please retest", right? or ping Alex?
yannd has joined #yocto
lthadeus has quit [Ping timeout: 260 seconds]
<RP>
landgraf: just reply to the series and mention I said we should retest, copy alex. It still applies ok
<landgraf>
RP: kk. thanks
lthadeus has joined #yocto
mckoan has joined #yocto
olani- has joined #yocto
florian has joined #yocto
neofutur_ has quit [Ping timeout: 260 seconds]
neofutur has joined #yocto
qorin has joined #yocto
wicki has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
lthadeus has quit [Remote host closed the connection]
<destmaster>
WARNING: SRC_URI is conditionally overridden in this recipe, thus several devtool-override-* branches have been created, one for each override that makes changes to SRC_URI. It is recommended that you make changes to the devtool branch first, then checkout and rebase each devtool-override-* branch and update any unique patches there (duplicates on
<destmaster>
those branches will be ignored by devtool finish/update-recipe)
<destmaster>
Any changes on extracted source is not detected by git
<rburton>
you're using overrides on SRC_URI in the recipe and devtool can't handle that easily because the source is different for each override
<rburton>
it tells you what to do to handle this case, it's a bit more work because the recipe makes things complicated
cslcm has joined #yocto
<cslcm>
Hey. I've written a recipe for a supporting library for one of my projects (custom version of qt5) but it appears as if the do_populate_sysroot stage never executes. I've checked that the recipe installs its files into its recipes-sysroot folder, but they never get deployed to the dependent package's recipes-sysroot (which is how i understand it's supposed to work) - how can i debug this?
<rburton>
thats not how its meant to work
<rburton>
just install to $D in do_install as normal and the default populate_sysroot task will populate
<rburton>
what is the problem you're actually having?
<rburton>
i'm guessing "a file i want to be in the sysroot isn't in it?"
<cslcm>
i'm installing package A to $D, but package B can't find it
olani- has quit [Ping timeout: 276 seconds]
olani- has joined #yocto
<rburton>
did you add A to DEPENDS in B?
<cslcm>
Yes. Package A installs to ${D}/usr/qt and i am providing -DCMAKE_PREFIX_PATH=${STAGING_DIR_TARGET}/usr/qt in the second recipe
<cslcm>
i'm guessing one of those is wrong
<rburton>
yes, if you're going to install in special locations then you need to tell the staging code
<rburton>
best to just install to $libdir so you don't have to go around telling everything that you're special
<cslcm>
it has to end up in /usr/qt on the final filesystem
<rburton>
if you insist, you'll want to set SYSROOT_DIRS in the recipe. see the default in staging.bbclass.
<rburton>
_has_ to?
<cslcm>
yeah, that's non-negotiable since it's hardcoded in supporting libraries (i know)
<rburton>
symlink :)
<rburton>
but yeah set SYSROOT_DIRS so the sysroot is correct
<cslcm>
thanks, i'll give that a try!
<destmaster>
why after a modification of a file in devtool brach git says there's "nothing to commit"
<rburton>
you didn't stage it? (git add)
<destmaster>
rburton: it's on stage
<rburton>
<shrugs> this is just a git repo
<rburton>
nothing yocto-special, its a git repo with branches
<destmaster>
I need to inspect the repo ...
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<destmaster>
Could someone please help me on doing this task? In the vendor meta I've a recipe bbappend file that addss some config files to the package. I need (in my bbappend) to replace the content of some files (defconf) and delete other files. I've tried using the devtool but seems that this files are not tracked in git, so I'm unable to generate patch
<destmaster>
files.
<destmaster>
what is the proper approach?
<cslcm>
@rburton, i've done this in my recipe - SYSROOT_DIRS:append = "/usr/qt" but it still doesn't seem to populate this dir
<cslcm>
ah, missing a space probably
thomas_34 has quit [Quit: Client closed]
kanavin has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<cslcm>
no it's still not being deployed anywhere... └─./tmp/work/cortexa17hf-neon-vfpv4-poky-linux-gnueabi/qt5/5.15.2-r0/recipe-sysroot/usr/qt is still the only place in the tree that it appears
Guest45 has joined #yocto
Guest45 has quit [Client Quit]
kanavin has joined #yocto
Guest7 has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<rburton>
cslcm: can you share the recipe? hard to debug when you can't see it.
olani- has quit [Ping timeout: 268 seconds]
qorin has quit [Quit: Client closed]
destmaster has quit [Quit: Client closed]
<cslcm>
@rburton, found that the install command wasn't putting files where i thought
frieder has quit [Ping timeout: 245 seconds]
<cslcm>
think i'm on the right track now..
<cslcm>
thanks
<cslcm>
okay, next problem: gitsm:// seems to bork with large repositories with lots of submodules and LFS objects - is there a better way?
<rburton>
no, file a bug
<rburton>
well, yes. do a git: fetch and manually fetch the submodules and lfs pieces. but that sucks.
<rburton>
better yet, backport, post patch, apply locally until its merged
<rburton>
fastest way to get something fixed in a stable branch is to send the patch
vladest has quit [Quit: vladest]
<cslcm>
the maintainers are interested in fixing bugs in stale brances?
<cslcm>
oh stable
<cslcm>
nvm xD
<rburton>
kirkstone is supported until 2026
Saur_Home has quit [Quit: Client closed]
Minvera has joined #yocto
Saur_Home has joined #yocto
<cslcm>
how do i override "found library in wrong location"
<rburton>
if that's a qa check then the end of the line has the error code which you add to INSANE_SKIP
<cslcm>
ah.. at the end of many many lines, thanks
frieder has joined #yocto
vvn has quit [Quit: WeeChat 4.1.2]
vvn has joined #yocto
jstephan has quit [Remote host closed the connection]
vladest has joined #yocto
<rburton>
RP: we never merged anything to let you get the directory from a layer name did we
neofutur has quit [Ping timeout: 256 seconds]
<rburton>
i should repost my layer_path() patch
neofutur_ has joined #yocto
<RP>
rburton: not sure :/
frieder has quit [Ping timeout: 240 seconds]
frieder has joined #yocto
thomas_34 has joined #yocto
Guest9 has joined #yocto
Guest9 has quit [Client Quit]
rob_w has quit [Remote host closed the connection]
skinny1979 has joined #yocto
<cslcm>
if my package prefix path is /usr/lib.... the package compiles into (e.g) tmp/work/cortexa17hf-neon-vfpv4-poky-linux-gnueabi/qt5/5.15.2-r0/recipe-sysroot/usr/lib .. should i then copy the whole lot into the root of ${D}?
<cslcm>
i'm quite confused about how everything is suppoed to work :/
<skinny1979>
hi everyone! In preparation for the new LTS release next year I'm trying to upgrade our kirkstone based system to a newer version. While almost everything works as expected on nanbield I ran into one issue with a current very simple recipe. To pinpoint which version did break that recipe I tested with langdale as well and that also breaks (while it
<skinny1979>
does on kirkstone). It's a very simple recipe which copies some files to the target file system based on certain conditions/flags. In some cases the recipe does not output any files (intended). While this works on kirkstone, on langdale I get " * opkg_solver_install: No candidates to install my-recipe (null)!"
<skinny1979>
When I force the recipe to produce output files, the required .ipk package is actually created and everything works as expected. Did anything change with regards to the handling of recipes that don't produce any output ? (at least that's the theory I'm working with right now)
RobW has quit [Quit: Leaving]
frieder has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
speeder has joined #yocto
frieder has joined #yocto
speeder_ has joined #yocto
speeder has quit [Ping timeout: 252 seconds]
speeder__ has joined #yocto
simone93 has joined #yocto
<rburton>
cslcm: i assumed you were setting the prefix to /usr/qt
<rburton>
then just tell it to install like normal
speeder_ has quit [Ping timeout: 276 seconds]
<yudjinn>
hey, never saw a response and my IRC closed, so Im sorry if I'm asking this again; I have a dts syntax error showing up in this snippet of my dts. It's saying the 17th line (I marked with <<<'s for visibility) has a syntax error and fails to parse: https://pastebin.com/pbRZdrhz
<yudjinn>
simone93: sorry, thanks! I missed a snippet in that though, that is defined above: https://pastebin.com/sK0WeAJn
lthadeus has quit [Remote host closed the connection]
olani- has joined #yocto
florian has quit [Ping timeout: 252 seconds]
<cslcm>
@rburton, i did have the prefix set to /usr/qt but i'm trying to play nice.. and it's causing me a headache
speeder_ has joined #yocto
<cslcm>
when i tried this: cp -r ${STAGING_DIR_TARGET}/usr/lib/qt ${D}/usr/lib/ it gave me a flood of red messages about breaking QA or something
<rburton>
why are you copying files from the sysroot?
roussinm has joined #yocto
speeder__ has quit [Ping timeout: 256 seconds]
<rburton>
generally, do_compile will build from $S and write binaries to $B. do_install then copies from B to $D
prabhakarlad has quit [Quit: Client closed]
<rburton>
the sysroots are read-only and not what you're building, but what you build against
<cslcm>
i'm supplying --prefix /usr/lib/qt to ./configure, and that results in qt installing the binaries in ${STAGING_DIR_TARGET}/usr/lib/qt
<cslcm>
(i had to supply my own configure and install step because the qt commercial build system is a bit unusual)
<cslcm>
i'll try to adjust it
<rburton>
if it installs into STAGING_DIR_TARGET then you're doing something else wrong
<rburton>
please do share the recipes if you want useful advice
<cslcm>
it will always install into the supplied --prefix
<rburton>
but you said the prefix is /usr/lib/qt
<cslcm>
yeah but yocto seems to automatically change that to tmp/work/cortexa17hf-neon-vfpv4-poky-linux-gnueabi/qt5/5.15.2-r0/recipe-sysroot/usr/lib/qt
<cslcm>
(recipe contains some proprietary stuff which i don't own, if i get really stuck i'll edit that out and share it)
florian has joined #yocto
<rburton>
cslcm: typically you configure with --prefix=$prefix which is /usr by default. you're passing /usr/qt or something, that's fine. at install time you tell it to install into $D which is workdir/image/ so you end up with files in workdir/image/usr/qt/...
<rburton>
with autotools/cmake that's done by setting DESTDIR=$D
<cslcm>
i can't change the directory at install time
<cslcm>
it's frustrating
<rburton>
you can't change the prefix no, because paths get hardcoded into the binaries
simone93 has quit [Quit: Client closed]
<cslcm>
i mean qt's "make install" doesn't accept a DESTDIR
<rburton>
it most certainly does
<cslcm>
this one doesn't
<cslcm>
anyway, no worries
ptsneves has quit [Ping timeout: 252 seconds]
<rburton>
without having a destdir you literally can't package the software for any distribution (redhat, debian, ubuntu, yocto) so either it does, or it's been hacked by people who don't expect their code to be actually used
speeder__ has joined #yocto
speeder_ has quit [Ping timeout: 264 seconds]
<cslcm>
looks like -extprefix at the configure stage is what is needed, to change the destination build dir
<cslcm>
which defaults to "sysroot + prefix" which is why i thought yocto was changing it
<rburton>
modern qt just uses cmake, what is this qt fork?
nerdboy has quit [Remote host closed the connection]
speeder__ has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
jmd has quit [Remote host closed the connection]
speeder_ has quit [Ping timeout: 268 seconds]
olani- has quit [Remote host closed the connection]
<khem>
if glibc is build just to honor gnuhash algorithm then such a binary wont run properly even
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
speeder__ has joined #yocto
<yudjinn>
is there a way to set the version for a dependency for just one recipe?
<khem>
RP: I am seeing qemuboot logs twice in qemu_boot_log.XXX the boot banner appear twice, second time it seems to be on "Yoe Linux 2023.11 qemux86-64 ttyS0" and first time it says "Welcome to ^[[1mYoe Linux 2023.11 (Istrian Pramenka)^[[0m!^M"
speeder_ has quit [Ping timeout: 255 seconds]
<khem>
I wonder if there is wrong trigger being sent to host to start running tests thinking that it has booted ?
<yudjinn>
most of my recipes use googletest 1.11, but I have one that needs 1.14; I dont wanna set PREFERREDVERSION at the conf level as that overwhites all of them; How can I do it just for that recipe?
<khem>
yeah its not easy to use different external dependency, you can bundle gtest with the package which needs it
Saur_Home has quit [Ping timeout: 250 seconds]
<yudjinn>
khem: you mean to fetch/configure/compile in the same recipe? oof
<khem>
yes, many packages bundle gtest for same reason
<yudjinn>
yuck, this is a CMake project, so I'll have to figure out how best to get that working
Saur_Home has joined #yocto
jmiehe has joined #yocto
speeder_ has joined #yocto
speeder__ has quit [Ping timeout: 256 seconds]
speeder_ has quit [Ping timeout: 256 seconds]
rm5248 has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
jmd has joined #yocto
Kubu_work has quit [Quit: Leaving.]
Chaser_ has quit [Quit: Chaser_]
speeder has joined #yocto
otavio has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #yocto
vladest has quit [Quit: vladest]
otavio has joined #yocto
<roussinm>
I would like to have two commits from master backported to kirkstone (bug fixes), but I'm not the author of the changes, does that matter if I submit to the mailing list?
jmiehe has quit [Quit: jmiehe]
<landgraf>
roussinm: it's ok to submit but keep original SoB
<landgraf>
(and add yours)
<roussinm>
landgraf: cool thanks!
speeder has quit [Ping timeout: 276 seconds]
speeder has joined #yocto
<khem>
git cherry-pick -s <commit> will keep all needed bits
<khem>
and add your SOB
<rburton>
roussinm: please post for nanbield too, unless they're already in that
<roussinm>
rburton: ok, let me check...
<rburton>
roussinm: worst thing would be for you to backport to kirkstone, then next year upgrade to nanbield and it breaks again. you'll spend a day debugging before realising why this all seemed familiar ;)
<roussinm>
indeed.
leon-anavi has quit [Remote host closed the connection]