<bgreen>
Is it possible to make a (image related) task run whenever the output of a git command changes? For example, I have a function in my image recipe that writes the output of 'git describe' to a file in /etc. It works, but the function is being cached. It won't rerun if, for example, I run (git tag <somename>) on the repo, causing the out put of 'git describe' to change. It will only rerun if something else causes the image to be
<bgreen>
rebuilt.
xmn has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
merit has quit [Read error: Connection reset by peer]
sgw has quit [Ping timeout: 246 seconds]
merit has joined #yocto
simonew has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
jmd has joined #yocto
alessioigor has joined #yocto
dash_hope has joined #yocto
dash_hope is now known as anish[1]
anish[1] is now known as peoliye
peoliye has quit [Changing host]
peoliye has joined #yocto
xmn has quit [Ping timeout: 268 seconds]
Kubu_work has joined #yocto
ehussain has joined #yocto
alperak has joined #yocto
Saur_Home59 has quit [Quit: Client closed]
Saur_Home59 has joined #yocto
peoliye has quit [Ping timeout: 250 seconds]
Saur_Home6 has joined #yocto
Saur_Home59 has quit [Ping timeout: 250 seconds]
rob_w has joined #yocto
mvlad has joined #yocto
ablu has quit [Ping timeout: 246 seconds]
ablu has joined #yocto
jmd has quit [Remote host closed the connection]
<RP>
bgreen: AUTOREV is what you want but it does come at a cost of always parsing that recipe
<RP>
bgreen: that will vary with the revision, but perhaps not always the description I guess. You could probably tweak things to make the description work
<RP>
harder though as you need a local repo for that which the system doesn't have at parsing, you can't do it remotely iirc
mckoan_ is now known as mckoan
rfuentess has joined #yocto
enok has joined #yocto
zpfvo has joined #yocto
Beartama has joined #yocto
<LetoThe2nd>
yo dudX
<mckoan>
LetoThe2nd: hey
leon-anavi has joined #yocto
altru has joined #yocto
Beartama has quit [Ping timeout: 264 seconds]
prabhakalad has joined #yocto
enok has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: Client closed]
alessioigor has joined #yocto
suihkulokki has joined #yocto
sukbeom has quit [Quit: Ping timeout (120 seconds)]
sukbeom has joined #yocto
tnovotny has joined #yocto
florian has joined #yocto
ehussain has quit [Ping timeout: 256 seconds]
ehussain has joined #yocto
ehussain has quit [Client Quit]
Jones42 has joined #yocto
cb5r has joined #yocto
<RP>
khem: that second error looks like $global_symbol_pipe isn't set. Will need debugging
mbulut_ has joined #yocto
florian_kc has joined #yocto
michael_e9 has joined #yocto
Jones42_ has joined #yocto
Jones42 has quit [Ping timeout: 240 seconds]
OnkelUlla has quit [Remote host closed the connection]
cb5r has quit [Ping timeout: 250 seconds]
OnkelUlla has joined #yocto
xmn has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
altru has quit [Quit: Client closed]
mckoan is now known as mckoan|away
cb5r has joined #yocto
<cb5r>
Is it possible to get some additional debug output of the QA checks? - I have a recipe that fails QA [arch] checks for some different architecture binary files despite having `INSANE_SKIP_${PN} += "arch"` (old bitbake 1.40) set in the recipe.
<rburton>
cb5r: is that set on the right package?
<cb5r>
rburton: I have a recipe called `app-engine-prebuilt.bb` which includes `recipes/rootfs/app-engine.inc` and it is set in the latter. I also tried putting into both files (inc + bb) but that didn't work either.
<rburton>
can you share the recipe? i'd also check that the arch test in your _very old_ thud release is actually per-package and not recipe-scoped.
<rburton>
EOL 2019, just saying
<cb5r>
I know @ EOL but unfortunately it's not in my control :/
<cb5r>
The .bb only downloads a tarball (via SRC_URI) and the .inc then does a `cp -r ${WORKDIR}/* ${D}/targetdir`.
<cb5r>
What is extremely weird though is that I do have some artifact tarballs for this here that do not fail. If i take one that works, repack it using gzip and use that - the QA check suddenly fails. if I then just delete those files that fail, the recipe succeeds. I cannot make sense of this
<rburton>
do you mean ${S}/*? WORKDIR/ will include a lot of stuff you don't want.
alessioigor has quit [Quit: Client closed]
cb5r31 has joined #yocto
<cb5r31>
rburton: You are right - it's actually `${WORKDIR}/SUBDIR/*` I am copying.
<rburton>
set S correctly and you can just copy ${S}
<rburton>
but without seeing the recipe its impossible to help, beyond 'look at the package_qa log'
<rburton>
also you don't need to cd to make a relative symlink
rob_w has quit [Quit: Leaving]
Saur_Home6 has quit [Ping timeout: 250 seconds]
lexano has joined #yocto
tnovotny has joined #yocto
amitk has joined #yocto
tnovotny_ has joined #yocto
<cb5r>
rburton: I don't know why the author (not me) did that. I guess curl and openssl shound be RDEPENDS as the app being deployed requires it to run on the device..?
tnovotny has quit [Ping timeout: 272 seconds]
<rburton>
possibly the app wants them and that satisfies the link generation
<cb5r>
Well, yes, the actual "app" being deployed definitely requires it on the device. But alongside there are many scripts and - what's causing me problems during build - binaries for some other architecture processor that's on the same board.
<cb5r>
How can I check that the arch test is per-package and not recipe-scoped? - And what would I need to change if it were only recipe scoped?
<rburton>
its per-package, i looked at insane.bbclass already
<rburton>
i'd start by skimming the package_qa log to see if anything interesting is in there. and checking that the package it warns on is the one you expect.
<cb5r>
One thing I just noticed in the do_package_qa los is that is runs "NOTE: Checking Package: app-prebuilt" without complaint. Then it does the same for "app-prebuilt-doc", "app-prebuilt-staticdev" and "app-prebuilt-dbg". << On the latter (*-dbg) it fails the check.
<rburton>
there you go
<rburton>
can you paste the actual message that bitbake says when you build the recipe?
<jclsn>
How is Qualcomm support looking in general? We are looking into new SoCs currently. I mean patching the kernel, device tree and U-Boot should be doable, but getting OP-TEE to work could be hard I think
<rburton>
cb5r: right, that says the package with the problem is app-prebuilt-dbg. this is why i said to check you were using the right package name.
<cb5r>
I understand now. I have actually no idea why/how/where these other packages with the doc, dbg etc. suffixes are created.
<rburton>
automatically
altru has joined #yocto
<rburton>
the -dbg package is all of the debug symbols from the main package
<cb5r>
rburton: OK, thanks! I get it now... Adding `INSANE_SKIP_${PN}-dbg += "arch"` to the recipe did the trick
<rburton>
relatively new releases actually spell out the recipe name
krissmaster has quit [Remote host closed the connection]
mvlad has quit [Ping timeout: 268 seconds]
mvlad has joined #yocto
nayfe has joined #yocto
<Jones42>
so I have a (more or less hello-world-)application written in rust. It works pretty fine until i try "devtool modify ...".
<Jones42>
do_compile tries to access the internet (Could not resolve host: index.crates.io) and fails.
<Jones42>
is there any difference between the workspace layer and the usual layers?
<nayfe>
Hello, i'm in the process of migrating from kirkstone to scarthgap, I'm wondering if there was a change of order between ROOTFS_POSTPROCESS_COMMAND step and do_install:append from recipes?
<nayfe>
I know it's ugly but i used to patch some rootfs files from recipes with postprocess stuff and it seems my modifications are made before do_install?
<nayfe>
overriding /etc/default/ssh for instance
tgamblin_ is now known as tgamblin
cb5r has quit [Quit: Client closed]
alessioigor has quit [Quit: Client closed]
alessioigor has joined #yocto
michael_e9 has quit [Quit: Client closed]
<nayfe>
ok it's maybe more read_only_rootfs_hook with overlayfs-etc new stuff conflicting with my custom solution
sa7mfo has joined #yocto
vthor has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
<KanjiMonster>
looks like the recent go linker changes (in kirkstone) broke arm at least for us; go links against /lib/ld-linux-armhf.so.3, but libc6 only ships a /lib/ld-linux.so.3 (on a cortex a15 machine)
<KanjiMonster>
sry, cortex a9
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Ping timeout: 250 seconds]
mvlad has quit [Remote host closed the connection]
tnovotny_ has quit [Remote host closed the connection]
florian_kc has joined #yocto
altru has quit [Quit: Client closed]
mbulut_ has quit [Remote host closed the connection]
RyanEatmon has joined #yocto
<RyanEatmon>
What happens if you have say 24 parallel bitbakes running on 24 different machines and all try to hit the hash equiv server over and over again?
RyanEatmon has quit [Client Quit]
<JPEW>
RyanEatmon: We've been trying to make the server able to scale better to handle those sorts of situations
<JPEW>
RP: We could try increasing the timeout
LocutusOfBorg has quit [Read error: Connection reset by peer]
RyanEatmon has joined #yocto
RyanEatmon84 has joined #yocto
RyanEatmon has quit [Client Quit]
<RyanEatmon84>
What happens if you have say 24 parallel bitbakes running on 24 different machines and all try to hit the hash equiv server over and over again?
mbulut has joined #yocto
LocutusOfBorg has joined #yocto
<JPEW>
RyanEatmon84: Reply in history if you have it
<RyanEatmon84>
I do not I was having issues.
<JPEW>
RyanEatmon84: We've been trying to make the server able to scale better to handle those sorts of situations
<RyanEatmon84>
Would that require a hash equiv server with a larger number of parallel server running?
<RyanEatmon84>
I might need to get a bigger server instead of the dual core one I have now
<JPEW>
RyanEatmon84: Ya, the server will either be limited by CPU time, or the database speed
<RyanEatmon84>
Ok... time to talk to IT about getting a bigger server. Thanks.
<JPEW>
If it's CPU time, you can spin up more (a change just recently merged that lets multiple servers share a TCP port to do load balancing, so you'd want that). If it's the database.... you'll have to figure that one out
<RyanEatmon84>
Yeah. I saw that and set it up to run two in parallel.
<RyanEatmon84>
I was just curious about running 24 bitbakes at the same time and hitting the server(s).
<JPEW>
RyanEatmon84: Ya, if you aren't consuming all the CPU, spinning up more server instances probably won't help
<JPEW>
Hard to say
<RyanEatmon84>
ok. so if the CPU is not high then this should be "ok".
<JPEW>
You _should_ be able to scale the server to handle that just fine; I can't tell you exactly what you would need to do to make it work
<JPEW>
Right
<RyanEatmon84>
there is no limit on the number of active connections to the server?
<JPEW>
Not in the hash server itself; the OS may have some restrictions
<RyanEatmon84>
ok. thanks.
<JPEW>
RP: near as I can tell, the raw TCP connection had no connection timeout. Websockets is a 10 second timeout by default
<JPEW>
TCP probably had the default OS TCP connection timeout, which is usually about 70 seconds
<ldywicki>
out of curiosity is there an existing blueprint how to get bitbake recipes under tests with i.e. github actions? I've seen multiple examples which involved variety of tools, but did not find any formal or informal recommendation in this area.
RyanEatmon84 has quit [Quit: Client closed]
jmd has joined #yocto
dash_hope has joined #yocto
dash_hope has quit [Changing host]
dash_hope has joined #yocto
<halstead>
RP: I'll have a hervserv up near valkyrie soon.
<RP>
JPEW: So we probably hit the 10s websockets timeout?
<RP>
halstead: ok, cool!
* JPEW
looks closely just to make sure
<halstead>
RP: I'm about ready to start rebooting. Should I let your a-full finish first?
<JPEW>
RP: Yes, in all of the recent timeout cases, it's been the 10 second websockets timeout
<RP>
halstead: no, kill it. It was started 7h ago and is clearly a slow one :(
<halstead>
Thanks.
rfuentess has quit [Remote host closed the connection]
<RP>
JPEW: hopefully scaling the servers will help
<JPEW>
Ya. 10 seconds may also be a little aggressive for a cross continent link
* RP
wonders whether to back out master-next changes and test with less risk of keep things in and hope for the best
<RP>
s/of/or/
<JPEW>
RP: Ya, either way it's confusing from an API perspective that the timeout is different than the invoke timeout, so I sent a patch to fix that
<RP>
JPEW: that makes sense and might help a bit too
<RP>
halstead: could we run a master-next after maintenance please?
<halstead>
Sure. ;)
<halstead>
RP: I just messaged in infra seconds before you.
<RP>
halstead: I just saw and have started one thanks
<RP>
JPEW: I included your patch
<RP>
halstead: if you need to stop valkyrie, that is fine too
<halstead>
RP: Thank you. I don't need to interrupt it yet. I'll message when I do.
<RP>
halstead: I'll be offline for a bit so just do it when needed
<halstead>
RP: Shall I start another afterward?
Saur_Home93 has joined #yocto
Saur_Home19 has quit [Ping timeout: 250 seconds]
Saur_Home3 has joined #yocto
jmd has quit [Remote host closed the connection]
Saur_Home93 has quit [Ping timeout: 250 seconds]
sa7mfo has quit [Quit: Client closed]
<bgreen>
RP: I don't think AUTOREV will get me what I need. This isn't for a recipe with a SRC_UR that includes a git repo I want to pull fromI. I have a toplevel local git repository, and layer repos are checked out beneath it. I use the variable WORKSPACE to point to the toplevel repo. During the do_rootfs or do_image stage of image creation, I just want a function to be executed any time the output of `cd ${WORKSPACE} && git describe`
<bgreen>
changes, so that I can write the description to a file under /etc in the rootfs.
<bgreen>
Currently, the only way I can get this to work is by setting the nostamp flag on the task in question. It isn't sufficient to set a variable to the result of a function that calls git describe, and then have my task have a dependency on that variable.
florian_kc has joined #yocto
mjm_ is now known as mjm
Saur_Home11 has joined #yocto
jmd has joined #yocto
Saur_Home91 has joined #yocto
Saur_Home3 has quit [Ping timeout: 250 seconds]
Saur_Home11 has quit [Ping timeout: 250 seconds]
Saur_Home45 has joined #yocto
Saur_Home91 has quit [Ping timeout: 250 seconds]
Saur_Home48 has joined #yocto
Saur_Home45 has quit [Ping timeout: 250 seconds]
enok has joined #yocto
sakman has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
Saur_Home19 has joined #yocto
Saur_Home48 has quit [Ping timeout: 250 seconds]
goliath has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
leon-anavi has quit [Quit: Leaving]
enok has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: Client closed]
zwelch has quit [Ping timeout: 272 seconds]
zwelch has joined #yocto
Saur_Home27 has joined #yocto
enok has joined #yocto
Saur_Home19 has quit [Ping timeout: 250 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
enok has quit [Ping timeout: 240 seconds]
genericum has joined #yocto
<RP>
bgreen: you'll need to force the recipe to re-parse every time, then you can make git describe be a vardepvalue of a variable your task depends upon
Saur_Home5 has joined #yocto
genericum has quit [Quit: Client closed]
Saur_Home27 has quit [Ping timeout: 250 seconds]
ajfriesen has quit [Read error: Connection reset by peer]
mbulut has quit [Ping timeout: 260 seconds]
ajfriesen1 has joined #yocto
mvlad has quit [Remote host closed the connection]
sgw has joined #yocto
Kubu_work has quit [Quit: Leaving.]
florian_kc has quit [Ping timeout: 272 seconds]
vthor has quit [Quit: kill -9 $pid]
nerdboy has quit [Ping timeout: 252 seconds]
cambrian_invader has quit [Ping timeout: 252 seconds]
nerdboy has joined #yocto
wooosaiiii has quit [Ping timeout: 255 seconds]
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
goliath has quit [Remote host closed the connection]