GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<frosteyes>
I have a local poky mirror, and noticed it was stop syncing, as it seems that the master branch was divergated. I guess the eunqueue stuff was merged to master by mistake, and then removed before the oe-build-perf-report commit.
<kaspt>
I got a problem after the poky update to 4.0.17 the freescale kernel get the localversion twice in the version string uname -r results with "6.1.57-fslc-fslc"
<kaspt>
any idea how to fix that I assume that its related any of this commits: 26f23535ee kernel: make LOCALVERSION consistent between recipes
<kaspt>
2b7c113459 kernel: fix localversion in v6.3+
<kaspt>
0b39955d14 Revert "kernel: fix localversion in v6.3+"
<kaspt>
552288e0c8 kernel: fix localversion in v6.3+
<kaspt>
59fcee90de kernel-devsrc: check for localversion files in the kernel source tree
<qschulz>
was there something specific that prevented you from sending it upstream?
altru has joined #yocto
kaspt has joined #yocto
<ernstp>
i have made a bbclass that resolves some stuff dynamically, it works a bit like AUTOINC/AUTOREV but for other things
<ernstp>
now if I have a slow build, there is a chance that the version is updated during the build! and then I get "When reparsing... the basehash value changed from"
<ernstp>
I wonder why that never happens with git AUTOINC/AUTOREV, it seems to be protected against that somehow... ?
<JaMa>
BB_SRCREV_POLICY?
<ernstp>
JaMa: hmmm, that's quite deep integration in the fetcher... ?
<ernstp>
i want these value to be set only during the initial parsing, and not re-evaluated later during the same run
<ernstp>
but for the next invocation of bitbake it should check again
<qschulz>
ernstp: make it a task and make the task never cache with nostamp maybe?
<qschulz>
exchanging info between tasks is "difficult" though (via files basically :/)
<qschulz>
ernstp: maybe you could provide code or at the very least a use case so we could try to guide you a bit better?
<ernstp>
right now I have a bbclass that populates a number of variables with an anonymous python function. then you put those variables in your SRC_URI and get the right artifact
<qschulz>
ernstp: what i've seen people do is have an external script that update a .inc file included by all recipes. That inc file would have SRC_URI:pn-<recipe_name> = "whjatever"
<qschulz>
so it's not included in bitbake per se but no issue of basehash having changed
<ernstp>
qschulz: I see... yeah that would be a quite different approac
<qschulz>
ernstp: having things changed at parse time/build time is a bit against Yocto philosophy though :/ this breaks reproducibility which is something most people are after
<ernstp>
qschulz: yeah i know... but it's pretty good when you're just tracking an item that get updated every day or so
<qschulz>
ernstp: and what in AUTOREV doesn't match your usecase?
<ernstp>
qschulz: it's not a git. it's a binary on an Artifactory server
<qschulz>
ernstp: oof. I guess another option is a customer fetcher, but this is going down the rabbithole I guess :)
<ernstp>
qschulz: lol :-) my thing works pretty well i feel, i'd just like to cache the value in the current "session" or something
<JaMa>
I would still go with updated .inc file so that it's clear what was built at that time and you can easily go back to it by checking out the right revision of that .inc file
<JaMa>
and you can easily switch between "stable" and "latest", do a promotion of the version upgrade from latest to stable after some validation etc
<ernstp>
JaMa: i see what you mean.....
<ernstp>
JaMa: i'd have to run it before the bitbake command then I guess
<JaMa>
you can have some separate job which will bump the values regularly and update such .inc file in your layer
<ernstp>
I'd like to avoid an endless list of commits with "updated version"...
<JaMa>
and this .inc file will be your "cached" value and if the build fails, then you can run the script locally and e.g. see if the failing component was already updated on artifactory and so on
<ernstp>
but i get that part yeah
<JaMa>
I guess depends on your exact use case, but I hate when things magically change between the builds
<JaMa>
especially when you cannot easily go back to the last working version
<qschulz>
the other downside could be a partial update, where you somehow manage to hit the moment during which one of the upstream git repo gets bumped, but not the other, and then you have build failures because you're building a version of a piece of SW which expects another specific version of its dependencies
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<ernstp>
qschulz: sure sure... but still, the strategy fits very well in some situations
<mbulut_>
qschulz, thx for the slides
<mbulut_>
I used devtool finish --force-patch-refresh busybox ../.. to create a new append in my layer
<mbulut_>
The generated .bbappend contains as expected FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" and the patch file is exactly named like the one from the upstream recipe
<mbulut_>
however when running the image build I still get the patch fuzz warning
<mbulut_>
hence my confusion...
<JaMa>
mbulut_: read the log.do_patch which will show you which file was found first
<ernstp>
maybe I could use an event handler to make sure my query only runs once
<mbulut_>
oh, wait
<mbulut_>
the .bbappend does not contain a SRC_URI ...
<qschulz>
mbulut_: doesn't have to
<mbulut_>
hmm
<mbulut_>
k lemme check the log
<qschulz>
are you sure FILESEXTRAPATHS:prepend := "${THISDIR}/<something>" is put in your bbappend?
<qschulz>
it should be exactly the above, only <something> replaced with the name of the directory(ies) from the current directory where the bbappend file is
<qschulz>
run bitbake-getvar -r recipe FILESPATH I think and you should have the path to the directory where your patch is
<mbulut_>
yeah, I'm sure: the patch is inside a 'busybox' folder, which is sibling to the .bbappend
<mbulut_>
see my message above about the .bbappend contents, it's what you'd expect
<qschulz>
mbulut_: my bad, somehow mussed one line :)
<mbulut_>
I checked the log.do_patch and indeed it picks up the patch from upstream, not mine
<mbulut_>
:)
<qschulz>
mbulut_: ok, is your bbappend actually parsed?
<qschulz>
mbulut_: you could be missing *.bbappend in your conf/layer.conf in BBFILES
<Guest62>
ok, the default do_task(){ : } can not be avoided I guess,
<mbulut_>
there's a 3rd party layer that .bbappends busybox from poky/oe-core to apply a patch they provided
<mbulut_>
this patch is fuzzy and I wanted to de-fuzz it in my own layer
<qschulz>
mbulut_: then you need to play with priorities/order in bblayers.conf IIRC
xmn has joined #yocto
<mbulut_>
qschulz, you said the BBFILE_PRIORITY only kicks in if the 3rd party layer just appends and not provides a full recipe, which is the case here
<mbulut_>
I'll try that now
<ernstp>
qschulz, JaMa: in my anonymous python function I should just be able set a variable after the query and then return early if it's run again?! if d.getVar("ARTIF_QUERY_DONE") == "1": return .... ?!
<qschulz>
ernstp: I do not know how multiple anonymous python functions are handled in bitbake, so maybe you don't want to return
<qschulz>
ernstp: also, i'm not sure if anonymous functions are always re-run or simply reparsed? if the latter, then you probably want to force a re-run as well with BB_DONT_CACHE
<ernstp>
qschulz: I have BB_DONT_CACHE in my .bbclass with this anonymous function
frieder has joined #yocto
<ernstp>
qschulz: yeah I'm not 100% sure what reparsing is exactly
<ernstp>
qschulz: but obviously it runs my http query again and changes the variables
<ernstp>
qschulz: and the problem only happens if a new artifact version appears exactly during the build
<ernstp>
ERROR: When reparsing florb-bin.bb:do_package_qa, the basehash value changed from ef925c19d5250678bdead7cf05be0386b1eae31ff7c70191b75e845f0f274fdd to 7a7b3a6e38dbe38973b4f5606a33e0eb688430212e33bea5711cf7b711346369. The metadata is not deterministic and this needs to be fixed.
Kubu_work has quit [Ping timeout: 252 seconds]
<mbulut_>
do I have to be worried about this? WARNING: No bb files in default matched BBFILE_PATTERN_yoctobsp '^/workspaces/sandbox/build/../sources/yocto.git/meta-yocto-bsp/'
<mbulut_>
the layer is from poky/kirkstone and I see no reason (checking layer.conf/BBFILE_PATTERN) why there should be "no bbfiles" reported...
<qschulz>
mbulut_: do you see bb files in that layer? because I don't, so the warning is appropriate?
kaspt has quit [Quit: Client closed]
<mbulut_>
qschulz, how about meta-yocto-bsp/recipes-bsp/gma500-gfx-check/gma500-gfx-check_1.0.bb ?
<mbulut_>
and there are a bunch of append recipes as well
<qschulz>
mbulut_: dropped in 4.3 so didn't see it
<mbulut_>
kk, I've checked out kirkstone branch and that has it
<qschulz>
mbulut_: I don't know, but I also have never included meta-yocto-bsp, do you really need it?
<mbulut_>
probably not as there is an own bsp provided for the machine but I was just wondering why the warning popped
Guest62 has quit [Quit: Client closed]
Kubu_work has joined #yocto
<mbulut_>
bumping the prio in my layer above the 3rd party one solved the patch issue btw :)
<mbulut_>
thx
manuel1985 has joined #yocto
jmiehe has quit [Quit: jmiehe]
simonew has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
kaspt has joined #yocto
frieder has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
tgamblin has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 252 seconds]
<manuel1985>
I'm getting the error 'nothing provides gst-redacted needed by nvidia-docker-redacted-1.0-r0.aarch64' but I don't understand why.
<manuel1985>
When gst-redacted_1.0.0.bb had errors, they were reported when building
tgamblin has joined #yocto
<manuel1985>
so the bitbake dependency chain seems alright
<manuel1985>
I'm unable to run 'bitbake recipe-name -e' because I can't go that deeply in the CI
<manuel1985>
any common mistakes you know of that I could have done?
<qschulz>
manuel1985: gst-redacted not having your MACHINE/arch in COMPATIBLE_MACHINE?
<manuel1985>
nvidia-docker-redacted.bb has RDEPENDS:${PN} = " ... gst-redacted ... "
<qschulz>
manuel1985: could also be that gst-redacted doesn't create a gst-redacted package?
florian__ has quit [Ping timeout: 260 seconds]
<qschulz>
manuel1985: that's not what I meant, something needs to generate this gst-redacted package
<qschulz>
so 1) the package that should generate gst-redacted package doesn't generate it
<qschulz>
2) the gst-redacted recipe isn't compatible with your machine so will never be built, thus the package will never be generated
<manuel1985>
(I started typing me messages before yours was on the screen, that was not a reply to your message)
<qschulz>
(sorry, fast fingers :) )
<manuel1985>
hmm.. In gst-redachted_1.0.0.bb I'm not touching PROVIDES and am providing a FILES:${PN}...
<manuel1985>
i whish I could do a local build
<qschulz>
manuel1985: that would be RPROVIDES probably anyway
<manuel1985>
oh ok
florian has quit [Quit: Ex-Chat]
<qschulz>
manuel1985: do you somehow completely override PACKAGES variable?
<qschulz>
maybe PN isn't in there anymore
<manuel1985>
qschulz: No I don't :/
<qschulz>
if you can, try to only build gst-redacted recipe with that machine. bitbake gst-redacted instead of my-image should do in most CIs?
zpfvo has joined #yocto
enok has quit [Ping timeout: 240 seconds]
altru has quit [Quit: Client closed]
kaspt has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 256 seconds]
Kubu_work has quit [Quit: Leaving.]
leon-anavi has quit [Quit: Leaving]
mckoan is now known as mckoan|away
zpfvo has joined #yocto
enok has joined #yocto
DvorkinDmitry has joined #yocto
<khem>
qschulz: yes time :)
<khem>
I am fine if someone takes the lead to upstream them
<khem>
there is too much fish to fry
<qschulz>
khem: ack :)
khem has quit [Quit: WeeChat 4.2.2]
zpfvo has quit [Quit: Leaving.]
khem has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
xmn has quit [Ping timeout: 260 seconds]
genericum has joined #yocto
<genericum>
how do I install nano on yocto ?
vthor has quit [Ping timeout: 268 seconds]
<genericum>
oh everything is done at build ?
jmiehe has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
vthor has quit [Ping timeout: 240 seconds]
amitk_ has quit [Ping timeout: 252 seconds]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
genericum has quit [Quit: Client closed]
florian has joined #yocto
alessioigor has quit [Quit: Client closed]
Jones42 has quit [Ping timeout: 255 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
vthor has quit [Ping timeout: 260 seconds]
tangofoxtrot has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]