qschulz has quit [Remote host closed the connection]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
qschulz has joined #yocto
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
vquicksilver has quit [Ping timeout: 264 seconds]
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
vquicksilver has joined #yocto
vquicksilver has quit [Ping timeout: 240 seconds]
Ablu has quit [Ping timeout: 255 seconds]
Ablu has joined #yocto
Daanct12 has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
kevinrowland has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
vquicksilver has joined #yocto
GParker_ has joined #yocto
geoffhp has quit [Ping timeout: 258 seconds]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #yocto
amitk has joined #yocto
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 240 seconds]
Vonter has quit [Ping timeout: 258 seconds]
Vonter has joined #yocto
Ablu has quit [Ping timeout: 240 seconds]
Ablu has joined #yocto
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 255 seconds]
Xagen has joined #yocto
Xagen has quit [Ping timeout: 255 seconds]
ykrons has quit [Ping timeout: 260 seconds]
Guest98 has joined #yocto
amitk_ has joined #yocto
goliath has joined #yocto
alessioigor has joined #yocto
amitk_ has quit [Ping timeout: 245 seconds]
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 255 seconds]
wacke has joined #yocto
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.5]
Daanct12 has joined #yocto
Circuitsoft has quit [Quit: Connection closed for inactivity]
mckoan|away is now known as mckoan
wacke has quit [Quit: leaving]
<landgraf>
(^_^)/
luc4 has joined #yocto
Guest81 has joined #yocto
Guest98 has quit [Ping timeout: 245 seconds]
vladest has quit [Quit: vladest]
frieder has joined #yocto
Chaser has joined #yocto
rob_w has joined #yocto
frieder has quit [Ping timeout: 258 seconds]
yates_work has quit [Ping timeout: 248 seconds]
Schlumpf has joined #yocto
<Guest81>
morning
<Guest81>
when creating the image, i saw that the recipe named "valgrind" was built. how can i find out which recipe has a dependency on this tool?
<landgraf>
Guest81: bitbake -g
<landgraf>
and then look for task-depends.dot
<Guest81>
landgraf thanks, i will try when the build is complete.
zpfvo has joined #yocto
vladest has joined #yocto
rfuentess has joined #yocto
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 258 seconds]
rfuentess has quit [Remote host closed the connection]
vladest has quit [Remote host closed the connection]
rfuentess has joined #yocto
vladest has joined #yocto
varjag has joined #yocto
leon-anavi has joined #yocto
geoffhp has joined #yocto
radanter has joined #yocto
GParker_ has quit [Ping timeout: 255 seconds]
<Guest81>
trying to build "arm-compute-library" and getting following error:
<Guest81>
ERROR: Multiple versions of flatbuffers are due to be built (/opt/yocto/sources/my-tegra-bsp/meta-openembedded/meta-oe/recipes-devtools/flatbuffers/flatbuffers_2.0.0.bb /opt/yocto/sources/my-tegra-bsp/meta-my-common/recipes-devtools/flatbuffers/flatbuffers_1.12.0.bb). Only one version of a given PN should be built in any given build. You likely
<Guest81>
need to set PREFERRED_VERSION_flatbuffers to select the correct version or don't depend on multiple versions.
<Guest81>
"meta-openembedded" layer priority 5, "meta-my-common" 50. why am i getting the error even though my layer is higher in layer priority?
<Guest81>
sorry, trying to build "onnxruntime"
<Guest81>
okay, i found my problem.
<mckoan>
Guest81: where do you set PREFERRED_VERSION_flatbuffers = "1.12.0" ?
<landgraf>
mckoan: they don't
zpfvo has quit [Remote host closed the connection]
<landgraf>
mckoan: only layers priority
zpfvo has joined #yocto
Chaser has quit [Quit: Chaser]
drkhsh has joined #yocto
<Guest81>
trying to build "arm-compute-library" and getting following error: pastebin.com/4Px4fe4q
<alberto_pianon>
RP: yesterday I had issues with my IRC mobile client entering and exiting the room, so I was not able to follow the conversation I started, sorry :)
<alberto_pianon>
RP: when you refer to a merged tree as the only use case in the past (for linux-yocto), what are you referring to precisely?
<bhstalel>
Is inkscape tool mandatory for creating SVG diagrams for docs ? Is there another easy tool ? I tried google slides but its format is incorrect.
<landgraf>
alberto_pianon: it's recipe's responcibility to work with second branch if needed
GParker_ has quit [Ping timeout: 272 seconds]
<rburton>
bhstalel: anything that makes SVG
<rburton>
eg draw.io
<bhstalel>
I tried to expot SVG from google slides but Michael said the format was incorrect, maybe I will try draw.io
<bhstalel>
rburton yes
<landgraf>
alberto_pianon: 2023-10-10 09:21:04 RP landgraf: right, it is assumed the recipe would do what it needed with the other revision
bhstalel has quit [Quit: Client closed]
<landgraf>
alberto_pianon: I've sent few testcases to bitbake-devel to test multiple branches usecases based on your question. You may want to take a look =)
neofutur has joined #yocto
<neofutur>
hi all, I just had a huge problem related to updating my ubuntu 18.04 host while builing on dunfell 3.1.10
<neofutur>
same problem that had been reported on this IRC channel one year ago :
<neofutur>
<Schlumpf> After Updating my host OS, I get an error when compiling icu_68.2: "tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ../lib/libicuuc.so.68)"
<neofutur>
( I m not the boss choosing to never update dunfell or ubuntu, just working on it )
<neofutur>
in the end the problem was that ubuntu 18 host upgraded libstdc++.so.6.0.25 to libstdc++.so.6.0.32
<neofutur>
problem fixed after switching back to the host to libstdc++.so.6.0.25
frieder has quit [Ping timeout: 255 seconds]
<neofutur>
but my question is : the clan way to fix that would have been to upgrade uninative ? any good practices about maintaining a long term project that started years ago on dunfell 3.1.10 ?
<alberto_pianon>
lnadgraf: thanks, just... where did you actually send the testcases? It seems I did not receive anything in bitbake-devel...
<mcfrisk>
neofutur: maintain your build env like yocto upstream does, e.g. build on same distro. If distros are an issue, introduce containers.
<alberto_pianon>
landgraf: thanks!
Ablu has quit [Ping timeout: 240 seconds]
kaitsh has quit [Quit: WeeChat 3.8]
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
<neofutur>
mcfrisk I am on the same LTS distro, but 18.04 updates changed libstdc++.so.6.0.25 to libstdc++.so.6.0.32
alessioigor has joined #yocto
<neofutur>
so "same distro" means " never update anything ? never ever apt update/upgrade ?
<mcfrisk>
neofutur: that is good, your distro version same as yocto upstream. Now yocto upstream has done something about this becuase maintainers and autobuilders are building dunfell.
<mcfrisk>
neofutur: I'm not expert on this but sounds like uninative needs to be recompiled
<neofutur>
on this project, the same old uninative from years ago is always used, stored in a local premirror
<neofutur>
so its older than the libstdc++.so.6.0.32 brought by ubuntu 18.04 updates
<neofutur>
never changing uninative/3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6
<neofutur>
including yocto/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6.0.29
<neofutur>
so, question could be : is it recommended to always upgrade uninative to newer versions, even thou you stay on an old dunfell 3.1.10 ?
<mcfrisk>
neofutur: yes, but changes in the build environment require updates now. for reproducible builds the build host environment needs to be preserved. All kinds of interesting updates come from Ubuntu and Debian updates too..
<mcfrisk>
neofutur: depends on what your requirements are. to me updating to latest dunfell on regular basis is the minimum. if this requires updates to build hosts, then so be it.
<neofutur>
I agree with that, but I m not the guy dediding that on the project
<neofutur>
*deciding*
<mcfrisk>
rebuilding uninative may be something on dunfell branch which has not yet been done on yocto project autobuilders, I presume, if this issue is not seen there yet.
<neofutur>
thanks for your answers !
frieder has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.0.5]
frieder has quit [Ping timeout: 255 seconds]
GParker__ has joined #yocto
luc4 has quit [Quit: Konversation terminated!]
luc4 has joined #yocto
GParker_ has quit [Ping timeout: 255 seconds]
neofutur has quit [Quit: Client closed]
<smooge>
.c
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
goliath has quit [Quit: SIGSEGV]
Minvera2 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
neofutur has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
GNUmoon has quit [Ping timeout: 252 seconds]
Haxxa has quit [Ping timeout: 255 seconds]
Estrella_ has quit [Remote host closed the connection]
Estrella_ has joined #yocto
Guest69 has joined #yocto
GNUmoon has joined #yocto
Guest69 is now known as rich1234
xmn_ has quit [Ping timeout: 258 seconds]
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 240 seconds]
Haxxa has joined #yocto
frieder has joined #yocto
neofutur has quit [Quit: Client closed]
frieder has quit [Ping timeout: 255 seconds]
amitk has quit [Ping timeout: 255 seconds]
Xagen has joined #yocto
MrFrank has quit [Read error: Connection reset by peer]
rob_w has quit [Remote host closed the connection]
<RP>
alberto_pianon: the other day I was basically saying old linux-yocto recipes used to use that approach. I don't think anything currently does any more
<RP>
alberto_pianon: those recipes internally looked at the other branch
Maxxed has quit [Ping timeout: 252 seconds]
sakman has quit [Quit: Leaving]
<qschulz>
tlwoerner: any gut feeling on the rk3588s patch for meta-rockchip kirkstone branch?
Guest98 has quit [Quit: Client closed]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest98 has joined #yocto
GNUmoon has quit [Ping timeout: 252 seconds]
Haxxa has quit [Ping timeout: 258 seconds]
zpfvo has quit [Ping timeout: 258 seconds]
Xagen has joined #yocto
zpfvo has joined #yocto
Haxxa has joined #yocto
GParker__ has joined #yocto
<tlwoerner>
qschulz: i'm happy to apply it as you've sent it. i don't feel that ATF was ever a good name for it (if we wanted to be specific it should have been TFA, but i prefer the more generic name going forward)
<tlwoerner>
so i'm not keen to perpetuate a bad name forever to ease a short-term back-porting issue
zpfvo has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
zpfvo has joined #yocto
GParker_ has quit [Ping timeout: 258 seconds]
<qschulz>
tlwoerner: sorry, got confusing signals from your sentence... could you please rephrase?
<tlwoerner>
you sent a rock-5b backport for kirkstone, removing the rock-5b-specific kernel and u-boot
<qschulz>
because the patch I sent keep using the ATF_DEPENDS which you seem to not like, but you say you want to apply the patch
<tlwoerner>
at the end you stated: [renamed INIT_FIRMWARE_DEPENDS to ATF_DEPENDS]
<tlwoerner>
and then pointed out we should probably talk about it
<tlwoerner>
so that's the thing to which i'm referring above
<qschulz>
Yup, got that. "i'm not keen to perpetuate a bad name forever to ease a short-term back-porting issue" vs "i'm happy to apply it as you've sent it"
neofutur has joined #yocto
<tlwoerner>
any backporting, going forward, will have to manually change the name from INIT_FIRMWARE_DEPENDS to ATF_DEPENDS, despite the added work
<tlwoerner>
i'm okay with that
<qschulz>
understood, thanks
<tlwoerner>
maybe i misunderstood your comment (your reply to your patch)? i thought you were asking that we revert INIT_FIRMWARE_DEPENDS back to ATF_DEPENDS in master so that backporting would be easier?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<tlwoerner>
i'm planning to apply your backport, Anthony's "Allow KERNEL_IMAGETYPE override v3" (with fixups), and an older "nanopi-m4b: add" that i submitted a while back that i don't think anyone reviewed (but is pretty straight-forward)
<tlwoerner>
qschulz: i still think there is a better way to specify that a Rockchip family is either using TF-A _or_ rkbin (i.e. my virtual/tpl patch)
<tlwoerner>
but i think it gets messy because, if i understand correctly, the things that rkbin provides and the things that TF-A provides don't completely mesh
Guest98 has quit [Quit: Client closed]
<qschulz>
tlwoerner: ok, so. Backporting from master to kirkstone is not fun because of the ATF_DEPENDS to INIT_FIRMWARE rename in master
<qschulz>
and it is technically possible that somehow a backport from master to kirkstone won't trigger a git conflict if the git context doesn't have ATF_DEPENDS/INIT_FIRMWARE in there
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<qschulz>
the issue I have with updating INIT_FIRMWARE in kirkstone branch is that this variable is overridable from conf file/bbappend
frieder has joined #yocto
<tlwoerner>
do you want to apply a rename patch to kirkstone ahead of your rk3588/s backport?
<qschulz>
and for downstream users, it isn't nice (though I personally do not care)
<qschulz>
so, the other thing we could do is have both variables for example to support both the current downstream users and also ease backports
GParker_ has joined #yocto
<qschulz>
e.g. something like ATF_DEPENDS ??= "${INIT_FIRMWARE}" (haven't thought too much about it tbh)
<qschulz>
spoiler alert, I like to torture my mind :)
MrFrank has joined #yocto
bhstalel has joined #yocto
<tlwoerner>
lol
GParker__ has quit [Ping timeout: 260 seconds]
Guest98 has joined #yocto
wyre has joined #yocto
tnovotny has quit [Quit: Leaving]
Ablu has joined #yocto
<paulg>
on a machine I've never used for yocto before...
<paulg>
Currently 1 running tasks (695 of 696) 99% |############################################################################################################## |
<paulg>
what the heck has it been doing for 90 minutes!?!
<bhstalel>
paulg Did a new terminal get opened ?
<rburton>
yeah it probably popped open a tmux or screen or something where you're not looking
<river>
yocto? *screams*
<paulg>
the build/session was already running under screen - probably confused the hell out of it?
<paulg>
Although I almost always do my stuff under screen, so nothing "new" about that workflow. Must be sth to do with this particular box.
* paulg
ignores it for now - not wanting to get sidetracked; didn't need that box anyway.
<paulg>
no new screen or tmux sessions according to "ps" - just odd.
luc4 has quit [Ping timeout: 240 seconds]
<paulg>
machine was just idle, pining for the fijords
vladest has quit [Remote host closed the connection]
amitk has joined #yocto
<rburton>
if you care, check the task log
<rburton>
or ignore it and move on ;)
<paulg>
for now I'm more interested in solving the ttyS1 missing getty on AB 1% of the time.
sakman has joined #yocto
rich1234 has quit [Quit: Connection closed]
Chaser has quit [Quit: Chaser]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<alberto_pianon>
RP: the thing is that someone could still use that feature somewhere. To handle this and other similar issues (eg. recipes with custom do_unpack functions like firmware-imx), I'm thinking about updating and checking the file index at given stages also after do_unpack, in order to be able to throw warnings for "known unknown" unpacked files, at least. Makes sense?
frieder has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
vladest has joined #yocto
flom84 has joined #yocto
bhstalel has quit [Ping timeout: 245 seconds]
flom84 has quit [Remote host closed the connection]
flom84 has joined #yocto
rsalveti has joined #yocto
xmn has joined #yocto
rfuentess has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
zpfvo has quit [Remote host closed the connection]
OnkelUlla has quit [Read error: Connection reset by peer]
radanter has quit [Remote host closed the connection]
_whitelogger has joined #yocto
Kubu_work has quit [Quit: Leaving.]
florian_kc has joined #yocto
rber|res has quit [Quit: Leaving]
flom84 has quit [Ping timeout: 260 seconds]
neofutur_ has joined #yocto
Guest67 has joined #yocto
<Guest67>
hi is there a command to know from which layer bitbake is inheriting a class from?
<Guest67>
from example if I have foo.bbclass in layer A and foo.bbclass in layer B, how can I tell which layer it is coming from?
neofutur has quit [Quit: Client closed]
<vmeson>
Guest67: You might try: bitbake -e core-image-minimal | tee log ; grep foo.bbclass . Does that help?
<landgraf>
Guest67: this depends on the order of layer appeareance in bblayers.conf iirc
<JaMa>
see BBPATH variable
<landgraf>
the easiest (at least for me) way is to add some sort of debug output into foo.bbclass itself and check where it came from.
<JaMa>
order of layers in BBLAYERS is the most important part, but layer.conf can do weird stuff with BBPATH (but most public layers are sane now and follow the convention)
<smurray>
I believe "bitbake-layers show-overlayed" shows classes
<Guest98>
I'm trying to build "arm-compute-library" in the same way but i get the same error you mentioned. i'm using scons.bbclass from kirkstone. Do you have any suggestions on how i can solve it?
<JaMa>
Guest98: meta-webos/recipes-upstreamable/arm-compute-library/arm-compute-library_22.08.bb:# scons here is too old for MAXLINELENGTH
<JaMa>
7b3d2a81f13 armnn: fix do_install with CMake 3.24.0
<JaMa>
0f036347fd2 armnn=r1 (fix build with gcc-13)
sudip_ has joined #yocto
<RP>
alberto_pianon: not really since anyone can add files at any time, they don't have to do it during unpack
<RP>
alberto_pianon: I think this is just a limit we have to accept
<RP>
alberto_pianon: the build creates files for other reasons, or changes them (with sed or reautoconf)
goliath has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
alberto_pianon has left #yocto [#yocto]
Chaser has joined #yocto
Chaser has quit [Quit: Chaser]
_whitelogger has joined #yocto
Vonter has quit [Remote host closed the connection]
Vonter has joined #yocto
leon-anavi has quit [Quit: Leaving]
sudip_ has quit [Ping timeout: 246 seconds]
sudip has joined #yocto
brrm has quit [Ping timeout: 255 seconds]
brrm has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian_kc has joined #yocto
pvogelaar has joined #yocto
<pvogelaar>
Hi, with devtool deploy-target I can deploy a package to the target via ssh. Is there a way to do this if the recipe was build with bitbake and not with devtool? So the files are in the build directory and not in the workspace.