chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
kroon has joined #yocto
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
sakoman has quit [Quit: Leaving.]
alessioigor has quit [Quit: alessioigor]
kroon has quit [Quit: Leaving]
kroon has joined #yocto
kroon has quit [Quit: Leaving]
kroon has joined #yocto
davidinux has quit [Read error: Connection reset by peer]
davidinux has joined #yocto
goliath has joined #yocto
moto-timo has quit [Changing host]
_whitelogger has joined #yocto
moto-timo has joined #yocto
ldericher has joined #yocto
rob_w has joined #yocto
<JaMa>
rburton: jonmason: Can you please remove meta-arm-toolchain/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY = "true"? or make it conditional on something, so that just including meta-arm-toolchain doesn't let your stuff dangling with just a warning?
warthog9 has quit [*.net *.split]
madisox has quit [*.net *.split]
dagmcr has quit [*.net *.split]
MWelchUK has quit [*.net *.split]
mario-goulart has quit [*.net *.split]
zibri has quit [*.net *.split]
alinucs has quit [*.net *.split]
manuel1985 has quit [Ping timeout: 248 seconds]
zibri has joined #yocto
alinucs has joined #yocto
madisox has joined #yocto
dagmcr has joined #yocto
mario-goulart has joined #yocto
MWelchUK has joined #yocto
warthog9 has joined #yocto
<JaMa>
rburton: jonmason: making meta-arm-toolchain optional (instead of hard dependency in LAYERDEPENDS_meta-arm) would be nice as well (if possible - I haven't checked what is really needed from arm-toolchain), but we have meta-arm in layers just because of dependency from meta-rockchip and it feels too much
<JaMa>
looks like meta-rockchip depends on meta-arm just because of TF-A and meta-arm on meta-arm-toochain just because of trusted-firmware-m, but there is also tf-a -> tf-m dependency in meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc:do_deploy[depends]+= "virtual/trusted-firmware-m:do_prepare_recipe_sysroot"
mckoan|away is now known as mckoan
<mckoan>
good morning
tre has joined #yocto
ptsneves has joined #yocto
tomzy_0 has joined #yocto
goliath has quit [Quit: SIGSEGV]
thomas__ has joined #yocto
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
thomas__ has quit [Client Quit]
<kroon>
hmm, no way to add HOSTTOOLS entry per recipe ?
mvlad has joined #yocto
frieder has joined #yocto
florian has joined #yocto
<ptsneves>
kroon no. It does not make much sense. What you want is a -native dependency
<ptsneves>
or add HOSTTOOLS globally
<kroon>
why doesnt it make sense ?
<ptsneves>
because recipe specific hosttools are -native recipes
<ptsneves>
what are you trying to achieve
Schlumpf has joined #yocto
Wouter0100 has quit [Quit: Ping timeout (120 seconds)]
<kroon>
that doesnt explain a goddman thing
<kroon>
i want to avoid building huge clumsy host tools, and just use the ones from my distro for this recipe
Wouter0100 has joined #yocto
pbergin has joined #yocto
<ptsneves>
kroon, if you are making this sort of question i am surely not going to explain you bitbake internals and design on why this is the case. What you want is not possible. bitbake builds host tools for reproducibility and host independence. Being huge makes no difference in theory because there is a thing called state cache. Good luck
<ptsneves>
if you want HOSTTOOLS it is a global thing and that is it
gsalazar has joined #yocto
selff has joined #yocto
<JaMa>
kroon: the hosttools are symlinked from global ${TMPDIR}/hosttools directory, so in theory it might work, but you would need to extend the functionality to create recipe-specific directory e.g. ${WORKDIR}/hosttools as well and add it to PATH
<kroon>
right
dev1990 has joined #yocto
<JaMa>
so currently it's not supported, but if you're willing to implement it, then I believe it would be possible as well as useful (e.g. meta-firefox adds python to HOSTTOOLS and that's annoying, because it makes python available everywhere instead of just firefox build)
<ernstp>
Ties in with the cve-check question you had mrybczyn[m]
granjow has joined #yocto
<granjow>
Hi! I'm trying to include a file from a parent directory with SRC_URI = "file://../../foo.txt", but it is not copied to the work directory. Is this not supported or am I doing it wrong?
<JaMa>
granjow: add the directory in FILESPATH instead
<kroon>
JaMa, yeah, and meta-bsp-imx8mp appends git-lfs and bison in its layer.conf, affecting all recipes in builds including that layer
<kroon>
(I guess ?)
prabhakarlad has joined #yocto
<kroon>
(Or does it only affect the recipes in that particular layer)
rob_w has quit [Remote host closed the connection]
<kroon>
looks like they affect *all* recipes :-/
<JaMa>
kroon: yes all of them
<JaMa>
kroon: once it gets symlinked from ${TMPDIR}/hosttools every build will see the new tool in its PATH
<kroon>
JaMa, oh yeah, the directory itself is shared anyway
<JaMa>
which sometimes causes a bit unexpected behavior, that you build something, then add layer like meta-bsp-imx8mp, meta-firefox, then rebuild the same thing and it might produce different results (without any change in "something")
<kroon>
JaMa, yeah, all the more reason for a per-recipe HOSTTOOLS then ..
<kroon>
HOSTTOOLS dir
<JaMa>
so any changes to HOSTTOOLS shouldn't be taken lightly
<JaMa>
agreed
<JaMa>
but if you can build your tool with -native recipe, then it's still better for reproducibility in long term
<RP>
I think git-lfs uses go or something which proved quite tricky at the time :/
<JaMa>
it can be a pain you pay once, but making sure that all possible builders of your layer will have the tool in right version and working correctly is long-term pain and you might not even have control over all the builders
<kroon>
JaMa, I'll agree to that, but I just don't wanna go through the hassle of that right now. just use the host version for now
<JaMa>
yes, depends on the tool and some tools are better staying compatible across versions and distros than others
goliath has joined #yocto
manuel1985 has joined #yocto
<granjow>
JaMa: Thanks, that worked! :)
<kroon>
JaMa, but.. with respect to surprising changing output - isn't HOSTTOOLS seeded into the task hashes ?
<Saur[m]>
kroon: Are you running the tool from the recipe or is it run from the build files? If it is the former, you can always run it as /usr/bin/foo (not very nice, but it works).
<kroon>
Saur[m], nah, its an autotools configure script that I want to trick into picking up the host versions. but I can workaround it for now by appending to HOSTTOOLS in my layer.conf
<LetoThe2nd>
yo dudX
bps has joined #yocto
bps has joined #yocto
pbergin has quit [Quit: Leaving]
<qschulz>
o/
<kroon>
JaMa, RP, looks like HOSTTOOLS is not included in task hashes. is there a good reason for not including it ?
<kroon>
or maybe not considered to change that often and not important enough to track I suppose
<JaMa>
I think it's partially because it would need to be global (like exported variables) so any time it changes, really everything gets invalidated and including just the list of tools (as HOSTTOOLS variable) doesn't prevent your host distro upgrading a tool to produce different result as well
<JaMa>
as long as the list is relatively short and includes mostly sane tools it's a risk we're willing to take, but extending the list with heavy often incompatible tools cannot be taken lightly
<kroon>
*nod*
<JaMa>
before HOSTTOOLS filtering (not long time ago) any recipe could see any tool on host in PATH, now they can see them only with full path or through HOSTTOOLS, so it's huge improvement
<JaMa>
maybe you can create a -native recipe which tests that the host tool is sane and then just installs a /usr/bin/<tool> symlink?
<kroon>
yeah, nothing wroing with HOSTTOOLS in general as I see it
<kroon>
JaMa, hah. yeah thats a nice idea
<JaMa>
that might be easy way to implement recipe-specific access to hosttool with a simple way to provide reasonable error whenever the tool is missing on host or has wrong version of something, without actually trying to build it
<rburton>
JaMa: i wasn't aware there was a dangling appends thing, i'll look
<rburton>
the dependency on the toolchain is needed for tfm right now, long-term plan is to just mandate multiconfig for building things like that
<JaMa>
rburton: can tfm be added in DYNAMIC so that for tfa you don't need to pull whole layer?
<rburton>
maybe. dynamics are a bit fragile
<JaMa>
BBFILES_DYNAMIC
<JaMa>
agreed, maybe it's just me never used multiconfig so I didn't see how it helps in this situation (better than BBFILES_DYNAMIC)
<JaMa>
FWIW: I haven't seen any dangling bbappends from meta-arm-toolchain itself (in kirkstone, honister, master builds), only now base-passwd from other layers (and that's why I've noticed that there is only a warning instead of expected error)
<rburton>
ah its because there's a grub bbappend in meta-arm-toolchain
leon-anavi has joined #yocto
<rburton>
hm maybe not, it predates that fix up
<rburton>
and is most likely legacy from the linaro import
<rburton>
i'll nuke it
<wCPO>
I have the kubernetes recipe from meta-virtualization failing building with: "Subprocess output:/bin/sh: line 1: opkg-build: command not found", looking at the PATH it contains "build/tmp/work/core2-64-poky-linux/defaultpkgname/1_v1.23.6+gitfbcfa33018159c033aee77b0d5456df6771aa9b5-r0/recipe-sysroot-native/usr/bin", notice "defaultpkgname" which
<wCPO>
should be "kubernetes". What could cause it to not use "kubernetes" as the "recipe name"?
<qschulz>
wCPO: try with bitbake -e kubernetes to check which variable is set to this value and the history of it to know where it comes from
<qschulz>
wCPO: pipe/redirect into a file because it's often several million of lines for the output of that command
janvermaete[m] has quit [Quit: You have been kicked for being idle]
<wCPO>
thanks, looking at the output the PN is to set kubernetes and none of the variables are set to defaultpkgname
florian__ has joined #yocto
<Saur[m]>
wCPO: If ${PN} is used outside of recipe context, it defaults to "defaultpkgname". E.g., `bitbake -e | grep '^PN='` will yield `PN="defaultpkgname"`.
granjow has quit [Ping timeout: 240 seconds]
selff has quit [Ping timeout: 252 seconds]
jpuhlman has quit [Ping timeout: 260 seconds]
jpuhlman has joined #yocto
tomzy_0 has quit [Quit: Client closed]
<wCPO>
Saur[m]: that make sense, in this case it is failing in the do_package_write_ipk task: https://paste.rs/mfm
prabhakarlad has quit [Quit: Client closed]
tomzy_0 has joined #yocto
selff has joined #yocto
<selff>
hi, where can i find all abbreviations? like sysconfdir,workdir. i searched a little but couldnt find any documentation.
<qschulz>
selff: bitbake.conf usually
<selff>
qschulz ty, found it.
<JaMa>
or 'bitbake -e' which shows them all including explanation where they are defined
starblue has quit [Ping timeout: 276 seconds]
Schlumpf has quit [Quit: Client closed]
starblue has joined #yocto
tomzy_0 has quit [Quit: Client closed]
Schlumpf has joined #yocto
zen_coder has joined #yocto
seninha has joined #yocto
ptsneves has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
zen_coder has quit [Remote host closed the connection]
zen_coder has joined #yocto
ptsneves has joined #yocto
<rburton>
RP: have you looked at the new CVEs yet?
<RP>
rburton: I looked at the list and thought we probably need to look at tiff and vim (yet again) but nothing more
<RP>
ernstp: "track" in what sense? for license issues or some other reason?
<RP>
ernstp: the new spdx manifest code would know how to track the debug symbols and get some license info that way
GNUmoon has quit [Remote host closed the connection]
<ernstp>
RP: license for example. or just the manifest. (was thinking of tuning the cve-check generation but then they would be excluded..)
<ernstp>
RP: i'll have a look at the spdx manifest then
<RP>
ernstp: the manifest code works off the debug symbols so it can know there is code in there from given code. Whether it can trace that given code back to the original recipe probably "depends"
<RP>
it should be able to
<ernstp>
RP: the old manifest code also?
<rburton>
RP: oh good, the tiff CVEs are master specific, not 4.3
<RP>
rburton: ah, handy :)
<RP>
ernstp: no
<ernstp>
RP: right, so only the new create-spdx.bbclass
<Guest87>
LetoThe2nd: it is called in the kernel-yocto.bbclass on line 217
<rburton>
Guest87: ask zeddii when he is here
<Guest87>
rburton: ok, any idea when that might be?
<rburton>
he's canadian so a couple of hours.
<rburton>
or, paste the actual error here and someone else might now
xmn has joined #yocto
tre has quit [Remote host closed the connection]
<Guest87>
"Could not locate BSP definition for xbox/tiny and no defconfig was provided"
<rburton>
how do you want to build the kernel? with a defconfig, or fragments?
<LetoThe2nd>
Guest87: it might make sense to elaborate a bit. what kind of bsp is this, and what makes you thing the yocto-provided kernel should support it?
<rburton>
as thats not a machine configured in linux-yocto, you need to provide the config somehow
<rburton>
tbh if you're experimenting, just providing a defconfig is easier in the short run
selff has joined #yocto
<Guest87>
rburton: yes, I can confirm that the files in my repository make it into the proper location on tmp/work
alicef_ is now known as alicef
fitzsim has joined #yocto
selff has quit [Quit: Client closed]
sakoman has joined #yocto
goliath has quit [Quit: SIGSEGV]
<wCPO>
this is really weird, now I tested with bare minimum yocto/poky build without any modifications and kubernetes still fails packaging: https://errors.yoctoproject.org/Errors/Details/657132/ , somehow the PN variable is getting set to a incorrect variable is my hunch
Juanosorio94 has joined #yocto
<zwelch>
RP
<zwelch>
RP: if my patch went in, I am mortified that I brought it up as an example. :( However, I know that I was carrying it in my local tree for quite some time after that, so I suspect that the version referenced in the recipe did not get bumped to include it (which is probably logical), but i know that i didn't see any e-mail follow up anywhere... (i still feel bad though)
<Juanosorio94>
I am trying to get yocto to build using a custom kernel, for an arm architecture. Im trying to use qemuarm first as a machine to test the image, but I am getting the following error:
<Juanosorio94>
ERROR: Nothing PROVIDES 'virtual/arm-poky-linux-binutils'. I have just copied the linux-yocto-custom.bb from the meta-skeleton directory into my layer, and made a few minor modifications. I dont know how to proceed atm. Would be very grateful of any tips, I am new to Yocto
<LetoThe2nd>
dgriego has joined #yocto
<LetoThe2nd>
Juanosorio94: so what does your machine look like, and on what release are you? can you put the kernel recipe into a pastebin?
<LetoThe2nd>
Juanosorio94: you can't set MACHINE and PREFERRED_PROVIDER in a recipe. MACHINE goes into local.conf, PREFERRED_PROVIDER either into the distro or machine config.
<LetoThe2nd>
Juanosorio94: and adding "arm" to compatible machine also won't work
<Juanosorio94>
im kind of overwhelmed tbh
<LetoThe2nd>
Juanosorio94: well my advice would be to start with the simpler things first. a layer, an image, a recipe. the kernel is quite special and requires correlation with the machine, so working on it is better done once you have some basic understanding of how things work.
<Juanosorio94>
where is the distro / machine config in the poky build dir?
<LetoThe2nd>
Juanosorio94: conf/machine and conf/distro. but you should not modify those. everything you do goes into your own layer.
<qschulz>
zwelch: ah, that is very likely indeed. kirkstone has it, I just checked
zeddii has joined #yocto
<qschulz>
but honister doesn't
<manuel1985>
I've got an idea for the next yocto project summit: "Debugging yocto recipes: What do if a configuration option doesn't do what it's supposed to"
<manuel1985>
I'd really like to learn how to do printf debugging in Bitbake
<rburton>
bbwarn or bb.warn, shell or python respectively
<rburton>
that's printf debugging. i've attached remote pdb to tasks before when they end up doing weird things in pythonland
<manuel1985>
The problem is that I don't speak Python at all. :(
<manuel1985>
Major obstacle.
<rburton>
bb.warn() is your friend then, it just prints what you pass to the console as a warning message
<manuel1985>
Hmm will give it a try
<manuel1985>
I'm currently diagnosing why KERNEL_MODULE_AUTOLOAD doesn't autload my kernel module.
<Guest87>
I'm building linux for a custom machine, and it appears that scc is crashing or something, it returns error code 1. I am using https://github.com/uglyoldbob/kernel_bsp as my repo for the BSP definition files
<Guest87>
it crashes/stops in kernel-yocto.bbclass at "configs="$(scc --configs -o ${meta_dir})""
goliath has joined #yocto
<Juanosorio94>
I need to set a defaulttune for my machine config ( I want to build first for qemuarm), is there any place wheer I can find all the available tune?
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Tyaku has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
<Guest87>
how can i go about troubleshooting why scc crashes/stops unexpectedly?
nemik has joined #yocto
jmiehe has joined #yocto
Juanosorio94 has quit [Quit: Client closed]
manuel1985 has quit [Remote host closed the connection]
yoctobeginner has joined #yocto
yoctobeginner has quit [Client Quit]
Guest70 has joined #yocto
<Guest70>
Hello everyone. I need some help with recipe. I'm creating an image but i need include a external project of my github (writen in python) in my build but i cant figure how to specify my recipe and git token
<Guest70>
any ideas?
Guest70 has quit [Quit: Client closed]
Guest70 has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #yocto
frieder has quit [Remote host closed the connection]
Guest70 has quit [Quit: Client closed]
Guest70 has joined #yocto
Schlumpf has quit [Quit: Client closed]
<rburton>
Guest70: you mean the github project is private so you need to provide authentication?
mckoan is now known as mckoan|away
Tyaku has quit [Quit: Lost terminal]
<Guest87>
how can i print the current directory in bitbake python functions? like bbwarn "${something}"
GillesM has joined #yocto
<RP>
Guest87: bb.warn(os.getcwd()) ?
<Saur[m]>
Guest87: Well, in shell code, `bbwarn "Current dir: $(pwd)"` should work
<Guest87>
thank you
florian__ has quit [Ping timeout: 240 seconds]
<rburton>
moto-timo armpit khem: did you know that unattended-upgrades in meta-python fails to build?
<Guest70>
rburton i have a bunch of projects on my github and i want to include all of them in my image. i create a new recipe but now i don't know how to build it correctly.
<khem>
rburton: yes started seeing this over weekend
<khem>
havent triaged it though
<rburton>
Guest70: write a recipe for each project
<manuel>
In inserted a `printf("MYMARKER " + modules)` at the line after, but when doing `bitbake -e virtual/kernel` I just get the unevaluated function body.
mihai has quit [Quit: Leaving]
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<Guest87>
what might prevent a patch.queue from being generated when I try to build my kernel? (in the tmp/work-shared/<machine>/kernel-source/.kernel-meta/patch.queue)
acki_ has quit [Remote host closed the connection]
acki_ has joined #yocto
florian__ has joined #yocto
<Guest87>
maybe it is config.queue I am looking for
<ernstp>
manuel: it's python so it should be print(). But try bb.info("")
<jsbronder>
manuel: `bb.warn(f"MYMARKER {modules}")` and then `bitbake -f -c package virtual/kernel`
<jsbronder>
printf isn't a python thing, you'd want print, but that output gets eaten. So bb.warn it is which will show up on the console.
<jsbronder>
and then you need to actually get that function to execute, you could just `bittbake virtual/kernel`, or you can force just the packaging task.
xmn has quit [Ping timeout: 258 seconds]
peoliye has joined #yocto
mvlad has quit [Remote host closed the connection]
GillesM has quit [Quit: Leaving]
xmn has joined #yocto
florian__ has quit [Ping timeout: 258 seconds]
pietrushnic has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
leon-anavi has quit [Quit: Leaving]
florian__ has joined #yocto
<RP>
zwelch: I think I was expecting someone would send a patch updating the recipe
<RP>
I can totally believe we've missed patches but that wasn't an example! :)
gsalazar has quit [Ping timeout: 252 seconds]
Tokamak has quit [Ping timeout: 255 seconds]
fitzsim has quit [Remote host closed the connection]
dgriego has joined #yocto
Tokamak has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<tlwoerner>
JaMa: neat! what host distro? not many seem to be hitting it. Richard found an easy reproducer, but I haven't had time to dig in yet. the work-around (ugly as it is) is to delete $TMPDIR before the build ;-)
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
chep` has joined #yocto
kevinrowland has joined #yocto
chep has quit [Read error: Connection reset by peer]