<tgamblin>
RP: yeah, I'm not sure what's wrong. Definitely blowing up on do_install_ptest_base, but either it's not showing up in the task log or I'm staring right at it and not seeing it
<tgamblin>
the "grep: Makefile: No such file or directory" line is misleading - that happens in do_install_ptest_base for 2.5.0 as well, but it finishes OK
florian_kc has quit [Ping timeout: 272 seconds]
vquicksilver has quit [Ping timeout: 255 seconds]
Starfoxxes has quit [Ping timeout: 252 seconds]
jmd has quit [Remote host closed the connection]
Starfoxxes has joined #yocto
kanavin has quit [Ping timeout: 272 seconds]
qschulz has quit [Remote host closed the connection]
<Guest1234>
I am trying to add gstremaer 1.22.5 recipe with dunfell for riacv64
<Guest1234>
*riscv64
<Guest1234>
I am frequently facing below issue,
<Guest1234>
ERROR: glibc-2.31+gitAUTOINC+1094741224-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command LANG=C git -c core.fsyncobjectfiles=0 clone --bare --mirror "git://sourceware.org/git/glibc.git" (downloads/git2/sourceware.org.git.glibc.git --progress (for
<Guest1234>
ERROR: Logfile of failure stored in: (tmp-glibc/work/riscv64-oe-linux/glibc/2.31+gitAUTOINC+1094741224-r0/temp/log.do_fetch.351906
<Guest1234>
ERROR: Task (meta/recipes-core/glibc/glibc_2.31.bb:do_fetch) failed with exit code '1'
<Guest1234>
ERROR: binutils-cross-riscv64-2.34-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command LANG=C git -c core.fsyncobjectfiles=0 clone --bare --mirror "git://sourceware.org/git/binutils-gdb.git" /downloads/git2/sourceware.org.git.binutils-gdb.git
<Guest1234>
ERROR: Logfile of failure stored in: /home/ankita/bin/sources/base-build/tmp-glibc/work/x86_64-linux/binutils-cross-riscv64/2.34-r0/temp/log.do_fetch.245987
<Guest1234>
ERROR: Task (/home/ankita/bin/sources/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_fetch) failed with exit code '1'
<RP>
Guest1234: first of all please use a pastebin for multiple lines of text
<RP>
Guest1234: secondly, those looks like fetch issues where it can't find sources as you have the network disabled and your source mirror is not up to date
<Guest1234>
how can I enable it?
Saur has quit [Remote host closed the connection]
Saur has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
frieder has joined #yocto
eicke has joined #yocto
rob_w has quit [Remote host closed the connection]
eicke has quit [Client Quit]
eicke has joined #yocto
zpfvo has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<eicke>
Hello first time here on the chat but full time yocto developer with at least some experiance :) Also have a very basic public yocto project for the ox64 board although that is only partly working as i lack some time to work on it.
paulg has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
leon-anavi has joined #yocto
sakman has joined #yocto
ptsneves has joined #yocto
<mckoan>
eicke: welcome!
eicke has quit [Ping timeout: 260 seconds]
florian has joined #yocto
eicke has joined #yocto
frieder has joined #yocto
eicke has quit [Ping timeout: 268 seconds]
mvlad has joined #yocto
alperak has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
jpuhlman has quit [Ping timeout: 268 seconds]
<RP>
Guest1234: presumably you have set BB_NO_NETWORK or BB_FETCH_PREMIRRORONLY somewhere?
ptsneves1 has joined #yocto
ptsneves has quit [Ping timeout: 272 seconds]
ptsneves1 is now known as ptsneves
<JaMa>
RP: I think the issue with the .bbappend ordering is that nobody knows how to deal with it in their layers (including me), I was in favor of removing it, because adding P_V isn't big deal and easy to adapt to (and I already did in our layers), but only the first build revealed that indeed .bbappends don't work well for us anymore
ptsneves1 has joined #yocto
<JaMa>
if we can sort them by reversed BBFILES order than, it might be still doable (as people who care already have to deal with BBLAYERS ordering to get BBPATH order right), so hopefully they will expect .bbappends to apply in the same order (except those dynamic-layers :/)
ptsneves has quit [Ping timeout: 246 seconds]
ptsneves1 is now known as ptsneves
frieder has joined #yocto
sakman has quit [Ping timeout: 272 seconds]
<RP>
JaMa: there are multiple issues. That is one of them but there are also a lot of really difficult expectations (e.g. I can't error if BBFILE_PRORITY is present as that would break some people's usage)
<RP>
JaMa: I can't really face trying to argue this any further right now
<RP>
JaMa: and yes, I'm frustrated/depressed about it
<JaMa>
understood
<RP>
JaMa: does BBFILES ordering control the appends order at present?
<RP>
JaMa: it should but no longer sure about anything
<JaMa>
it doesn't at present AFAIK
<JaMa>
I'm just saying that it could be a way how to "deal with it" if we let BBFILES to control it
<RP>
JaMa: it is how I thought it was working
<RP>
JaMa: it would probably work for some and not for others and we'd be back to the start again
* JaMa
too, I've even found that bitbake commit where I said that bbappends no longer apply based on BBFILE_PRIORITY and thought that I was wrong back then
<JaMa>
because of us (LGE with mcf) the BBFILE_PRIORITY is tied with BBLAYERS order and indirectly results in BBPATH and BBFILES order, so it's easy to confuse the "4 dimensions" of this
<RP>
JaMa: right, it is all too complicated
<JaMa>
should I try some experiments with BBFILES ordering to see at least if that works in our (fairy complicated) layer setup?
<JaMa>
what Peter said looks like relatively good start
<JaMa>
"adding a bbappend.reverse() in collect_bbfiles()"
frieder has quit [Ping timeout: 264 seconds]
mulk has quit [Ping timeout: 272 seconds]
mulk has joined #yocto
<RP>
JaMa: it would be worth looking at as we do need to do something with this
gsalazar has joined #yocto
Guest1234 has quit [Quit: Client closed]
<Ad0>
upgraded to kirkstone
<Ad0>
ERROR: Found *.bbappend in /home/blah/build/workspace, but could not determine EXTERNALSRC:pn-*. Maybe still using old syntax?
<RP>
JaMa: looking at the code, it currently re-sorts BBFILES according to priority. That should mean with the removal that bbappends are found in BBFILES search order. I therefore worry a bit about this "reverse()" you and Saur mention
<Ad0>
I am trying to use devtool modify u-boot in kirkstone
<Ad0>
and it ain't workin'
<JaMa>
RP: yes, but BBFILES order in my and Saur builds are in reversed order of priority (from highest) and now the .bbappend in highest priority layer is applied first instead of last
<JaMa>
RP: so if I have .bbappend setting SRC_URI in OSE and internal build, then before priority drop OSE as applied first and then internal build overwrote it, without the priorities it doesn't
<RP>
JaMa: do you both order BBLAYERS with the "most important" layer first? Despite saying that layers should always append to BBFILES?
frieder has joined #yocto
<JaMa>
in theory I could BBMASK the .bbappend from OSE, but in most cases I'm overwritting only some variable (and still need e.g. additional PACKAGECONFIG added by .bbappend in OSE)
<JaMa>
RP: from what he wrote in the e-mail I believe yes
<Ad0>
fixed it - it was old bbappends from dunfell that needed changing from another recipe ...
<RP>
this was never how it was meant to be used :(
<JaMa>
build is still running with reversed() added, but so far no failure (even when locked-sigs still show a lot of differences)
<RP>
JaMa: in theory you could reverse the ordering in BBLAYERS insead?
<RP>
I guess that does potentially break something else
<JaMa>
but would need to change all BBPATHs at the same time
<RP>
right
<JaMa>
there would probably still be issue with the dynamic-layers entries, the bbappend list from dl9pf shows a lot bbappends in dynamic-layers
jpuhlman has joined #yocto
frieder has quit [Ping timeout: 256 seconds]
<JaMa>
while we have only 13 bbappends in dynamic-layers (so it might just happen to work as before in these cases) as from these 13 only samba and packagegroup-meta-oe have multiple bbappends
<JaMa>
and this one is "safe" as both just append to RDEPENDS
<RP>
At this point I'm going to propose something entirely new after April. Everyone will have to rewrite and reconcile things
<JaMa>
ack
<mcfrisk_>
RP: thanks for trying to sort out and simplify the layer ordering in various cases. I have been bitten by this too many times and welcome any change to simplify things even if it means many current setups break.
ptsneves has quit [Ping timeout: 252 seconds]
<rber|res>
I am wondering why, if I inherit npm, nodejs is not properly installed out of the box. I need to manually add RDEPENDS: brotli, c-ares, icu.
<rburton>
rber|res: are those rdepends needed in nodejs itself and should just be added?
<rber|res>
@rbuton I need to check this
Guest77 has joined #yocto
sakman has joined #yocto
linfax has quit [Ping timeout: 268 seconds]
frieder has joined #yocto
Guest77 has left #yocto [#yocto]
eicke has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
lexano has joined #yocto
rfuentess has joined #yocto
frieder has joined #yocto
eicke has quit [Ping timeout: 272 seconds]
alperak has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
xmn has joined #yocto
<rber|res>
@rburton buildhistory tells me that the RDEPENDS (and DEPENDS) look good for nodejs
<rber|res>
@rburton, so I guess it's not enough to inherit the npm class, but I also need to RDEPENDS on nodejs in my recipe which uses nodejs
<rburton>
rber|res: you could argue that inherit npm should mean a rdepends on node, but also arguably you might not want it in the main package. so yes, rdepend on nodejs.
<rber|res>
@rburton - well go and python also behave like that, you need to RDPENDS on phython and go-runtime
<JaMa>
you can use npm.bbclass to produce a package which has no javascript in it
<RP>
derRichard: I've seen a lot worse and I have wanted to find a way to have a 64 bit kernel on 32 bit platforms for a while...
<derRichard>
:-)
otavio has quit [Ping timeout: 240 seconds]
<RP>
I'd probably put the python functions into lib somewhere, make it conditional on being arm32, turn the variable manipulations into overrridden conf entries and turn it into an optional inc file
<JaMa>
derRichard: is it new requirement for CONFIG_COMPAT_VDSO or was it always like that?
<derRichard>
JaMa: it was always like that. you don't need CONFIG_COMPAT_VDSO for CONFIG_COMPAT on arm64. but if your arm32 apps need a vdso, you need CONFIG_COMPAT_VDSO too
_whitelogger has joined #yocto
otavio has joined #yocto
<derRichard>
RP: one thing that is still ugly IMHO, CROSS_COMPILE_COMPAT= is the full path to the toolchain. but i guess it is by design that only the primary (64 bits) toolchain is in PATH
<rburton>
yocton: thanks for the cve work!
<yocton>
rburton: wait till you see how I've messed up the ordering on the wiki page :p
sukbeom has quit [Quit: Ping timeout (120 seconds)]
sukbeom has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
<khem>
RP: I think we need another fix for cpio test upgrade since I am seeing a timing out of sync failure on AB but it works locally here but this one works on AB too - https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut&id=5cc417a9a885b9ab4462686dfc9ab0aced5ea389
<khem>
RP: with this build for qemuriscv64 looks promising thus far
GNUmoon has joined #yocto
sakman has quit [Ping timeout: 259 seconds]
jmd has joined #yocto
frieder has quit [Ping timeout: 256 seconds]
gchamp has joined #yocto
<RP>
khem: interesting. I wonder why riscv is particularly prone to it
<vmeson>
I'm trying to show people that the number of recipes in Yocto is tens of 1000s so it's probably ~ 1/4 the size of Debian's package list. I'm guessing at the numbers.
vmeson has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Ping timeout: 250 seconds]
<rburton>
alimon: if you want to be the new ptest-runner maintainer then there's some patches on the yocto@ list to review/merge
<moto-timo>
rburton: no, but that basically means Django is taking too long to respond to the query and nginx is giving up.
vmeson has joined #yocto
amitk has quit [Ping timeout: 272 seconds]
<moto-timo>
rest api is probably sufficient for the query too, but not sure we can do enough filtering with the current simplistic api
<moto-timo>
rburton: so yes, that has what vmeson is after... we just need "someone" to figure out what is crashing Django (OOM?)
<moto-timo>
rburton: it crashed my own instance too, so something ugly.
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
jmd has joined #yocto
<khem>
RP: btw. something in master-next is causing rv32 qemu to throw all kinds of crashes, I am suspecting kernel upgrade to 6.6.15 patchset might be it, I have started a build with out it
<jdiez>
hi, python3-pyyaml got included in my image build since I added the meta-ros* layers to it. However, I get this build error:
<jdiez>
ERROR: python3-pyyaml-6.0-r0 do_package_qa: QA Issue: /usr/lib/python3.11/site-packages/yaml/_yaml.cpython-311-aarch64-linux-gnu.so contained in package python3-pyyaml requires libyaml-0.so.2()(64bit), but no providers found in RDEPENDS:python3-pyyaml? [file-rdeps]
<gmorell>
nothing looks out of place on the django query for that template, and nothing is being done on that template that would trigger an n+1, but I'm also not sure if the annotations trigger a [select/prefetch]_related
<jdiez>
indeed, nothing yaml-related is in meta/recipes-devtools/python/python3-pyyaml_6.0.bb. But should it be?
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<RP>
alimon: nice to see you! :) we're running a bit behind with patch review/merging atm
<RobW>
jdiez: I can help you. What Yocto release and ROS 2 distro are you using?
<jdiez>
RobW: ok, I'll let you know in a few minutes as well. Thank you!
<RobW>
There are 3 layers you need to add: meta-ros2, meta-ros-common, and meta-ros2-humble
<jdiez>
yeah, I have them
<jdiez>
I am building core-image-minimal with a custom distro config, which just adds ros-core to IMAGE_INSTALL
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
<moto-timo>
looks like the python3-pyyaml recipe needs a PACKACONFIG for libyaml
<moto-timo>
and ptests
<moto-timo>
the usual dance
<moto-timo>
^PACKAGECONFIG
<jdiez>
moto-timo: can you link to a similar python package that already has the changes you mean?
florian_kc has joined #yocto
<moto-timo>
jdiez: I'm the maintainer for python3-pyyaml... so I'll just fix it
<jdiez>
ah ok cool!
<moto-timo>
jdiez: you might need to request a backport if you are not using master
<moto-timo>
jdiez: but once you see the patch hit the mailing list you can just use it for a bbappend (I'll split the PACKAGECONFIG and the ptests into separate commits... assuming I can even get the ptests to run)
<moto-timo>
jdiez: my first guess (not tested yet and I didn't look up the syntax) is PACKAGECONFIG[libyaml] = "--with-libyaml,--without-libyaml,libyaml"
<jdiez>
RobW: I found that BBMASK did not have the rpi exclusion in my build, not entirely sure why, but it makes sense to append that at variable expansion time
<moto-timo>
jdiez: and then you'd want PACKAGECONFIG = "libyaml"
<jdiez>
moto-timo: (sorry I'm a yocto noob, still learning :)) my understanding is that that would cause `--with-libyaml,--without-libyaml,libyaml` to be appended to some compilation command of python3-pyyaml?
<jdiez>
okay I see in the readme, it's an argument to python setup.py
<moto-timo>
jdiez: it would add --with-libyaml to the compilation and libyaml as an RDEPENDS
<jdiez>
ok got it, thank you!
ptsneves has joined #yocto
<moto-timo>
not tested... just going by memory and what I think should work ;)
<jdiez>
and one more noob question: how had it previously worked without this additional flag to setup.py before? it doesnt look like a recent change to pyyaml
<moto-timo>
jdiez: either it recently (maybe in the 6.0.0 upgrade?) added detection of libyaml "automagically" and is now getting host contamination or... we've just been lucky
<moto-timo>
jdiez: this is why we want run time tests for everything we can (ptest which means "package test")... but it doesn't come for free... someone has to figure it out and it takes time to run the tests... and sometimes the test dependencies are... massive
<jdiez>
RobW: same issue with mickledore-next
<jdiez>
moto-timo: what do you mean by host contamination in this context? I'm running bitbake inside a crops container btw
<moto-timo>
jdiez: it is possible it would find libyaml on the host (or in your case somehow in the container)
<moto-timo>
jdiez: and then very "helpfully" compile it in... without telling you
<jdiez>
haha :) looks like it's not installed in the container, though
sakman has joined #yocto
<jdiez>
moto-timo: looks like `PACKAGECONFIG ??= "libyaml" \n PACKAGECONFIG[libyaml] = "--with-libyaml,--without-libyaml,libyaml"` does the trick
<moto-timo>
\o/
sakman1 has joined #yocto
sakman has quit [Ping timeout: 276 seconds]
sakman1 is now known as sakman
<kanavin>
derRichard, saul is listed, but de facto no work in that area had happened, either in fixing isues or adding features
<kanavin>
I guess there are grades of maintainer, so this is the minimal one
<derRichard>
ok. sooner or later i'll have to dig into the devtool sources. some of my customers use it and there're issues
<kanavin>
derRichard, the more people understand its source code, the merrier of course. I barely know the upgrade functions, just enough to keep it alive in AUH context.
<kanavin>
recently there have been improvements to devtool from adrian peter and julien, you can see them in poky master log. So at least there's a few people who looked at it :)
vladest has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 272 seconds]
<vmeson>
moto-timo: rburton : re number of recipes and the django crash - ugh and I'm sorry that I can't help with that right now.
<moto-timo>
vmeson: you might try the stats url on an internal WR layerindex...
<moto-timo>
vmeson: or login and choose Statistics from under the Tools menu
jmd has quit [Remote host closed the connection]
<vmeson>
moto-timo: good idea. I don't actually have a layerindex login for OE or WR but I know people who do...
<moto-timo>
vmeson: it would be an interesting data point if it works on an internal WR instance (that happens to have more RAM or something)
<vmeson>
yep
<vmeson>
I'll find out and let you know.
prabhakarlad has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<gmorell>
I've updated crun to deal with the new cve by changing the srcrev in a bbappend, but I'm being trolled by the fact that it has the ability to use cpusets now and I'm not sure how to enable them on one of my arches, I set the flags for CONFIG_CGROUP_CPUSET=y + CONFIG_CPUSETS=y, but they're not being properly enabled in my image, google has been awful for this stuff lately
vladest has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RobW>
jdiez: Can you point me to the steps you are using to do the build? I can try to recreate your environment.
<dvergatal>
generally I was thinking about having same filename, different content and in different directories of recipe only one install command for both, this is possible in case of different distros or machine
<dvergatal>
but than I would have more distros just to distinguish is it development or release build which is stupid...
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
gsalazar has quit [Ping timeout: 264 seconds]
<dvergatal>
hmmmm can I INHERIT from MACHINE?
florian_kc has quit [Ping timeout: 272 seconds]
<dvergatal>
ha I can use DISTROOVERRIDES :D
<RP>
khem: I guess it is useful to know it is the kernel for rv32. Having the failure and warnings for the ptests should also help to start with places to look into issues