sotaoverride has quit [Remote host closed the connection]
Habbie has quit [Ping timeout: 244 seconds]
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
Habbie has joined #yocto
nerdboy has joined #yocto
sanbeam has joined #yocto
sanbeam has quit [Changing host]
sanbeam has joined #yocto
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 244 seconds]
nerdboy has quit [Remote host closed the connection]
sanbeam9 has joined #yocto
sanbeam has quit [Ping timeout: 260 seconds]
nerdboy has joined #yocto
sanbeam18 has joined #yocto
tgamblin_ is now known as tgamblin
sanbeam9 has quit [Ping timeout: 260 seconds]
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 260 seconds]
sanbeam18 has joined #yocto
nerdboy has quit [Remote host closed the connection]
sanbeam9 has quit [Ping timeout: 248 seconds]
sotaoverride has joined #yocto
sanbeam9 has joined #yocto
sanbeam18 has quit [Ping timeout: 260 seconds]
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 260 seconds]
sotaoverride has quit [Ping timeout: 255 seconds]
jclsn has quit [Ping timeout: 276 seconds]
sotaoverride has joined #yocto
jclsn has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
sanbeam18 has quit [Ping timeout: 276 seconds]
Jones42_ has joined #yocto
Jones42__ has quit [Ping timeout: 246 seconds]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
laravelnewbie has joined #yocto
laravelnewbie has quit [Client Quit]
sanbeam18 has joined #yocto
sanbeam9 has joined #yocto
jmd has joined #yocto
sanbeam18 has quit [Ping timeout: 260 seconds]
xmn has quit [Ping timeout: 260 seconds]
sanbeam9 has quit [Ping timeout: 276 seconds]
BenBE has quit [Ping timeout: 246 seconds]
ray-san has joined #yocto
Minvera has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
Vonter has quit [Ping timeout: 272 seconds]
BenBE has joined #yocto
Vonter has joined #yocto
rob_w has joined #yocto
wojci has joined #yocto
fotte has joined #yocto
Jones42_ has quit [Ping timeout: 246 seconds]
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
rfuentess has joined #yocto
goliath has joined #yocto
Kubu_work has joined #yocto
alessioigor has joined #yocto
florian has joined #yocto
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley_ has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Jones42_ has joined #yocto
Jones42_ has quit [Ping timeout: 248 seconds]
enok has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
enok has quit [Ping timeout: 248 seconds]
mbulut_ has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
pvogelaar has joined #yocto
pvogelaar has quit [Client Quit]
pvogelaar has joined #yocto
leon-anavi has joined #yocto
mvlad has joined #yocto
<Lihis>
it seems that if I do `devtool modify some-recipe`, it won't affect the `some-recipe-native`? If I try to `devtool modify some-recipe-native` I get "Another variant of recipe some-recipe-native is already in your workspace". Is it possible to modify both native and the non-native version at the same time?
<olani>
Lihis: Yes, as long as they don't have S = "${B}". Go to workspace/appends/some-recipe.bbappend and add EXTERNALSRC:pn-some-recipe-native = ".../workspace/source/some-recipe" . Should be the same path as EXTERNALSRC:pn-some-recipe. If there is a EXTERNALSRC_BUILD:pn-some-recipe variable you can't do this. At least not in trivial cases.
<olani>
Lihis: The presence of EXTERNALSRC_BUILD typically means S == B.
<Lihis>
olani: that does the trick, thanks!
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
florian has quit [Quit: Ex-Chat]
rob_w has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
<landgraf>
Weird issue. Two machines (AWS codebuild env and localhost). Same layers, same local.conf, no sstate cache. Codebuild fails because of one of the zip files not found (it's in the SRC_URI list of the recipe which is not built into the image), localhost one works fine. If I remove problematic recipe alltogether then build works.
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
<RP>
landgraf: how far through the tasks does the zip file make it? You probably need to work out if it is a do_fetch or do_unpack issue or something later
sakoman has quit [Ping timeout: 246 seconds]
<landgraf>
RP: Looks like it's fetcher: 'Unable to get checksum for emqx-viso SRC_URI entry viso_agent.zip: file could not be found' is in __init__.py
<landgraf>
RP: Simple "touch viso_agent.zip" "fixes" the problem even in codebuild env so I'm lost :-/
<RP>
landgraf: does it list out where it is looking? Is it some kind of cwd issue?
<landgraf>
RP: it does. I don't understand why it tries to get checksum of SRC_URI it's not going to unpack/build at all and why it does it only in specific environment :(
<landgraf>
maybe it's codebuild's weirdness. I saw few already (like $HOME not set which cause connectivity_check failures)
sakoman has joined #yocto
wojci has quit [Ping timeout: 246 seconds]
<RP>
landgraf: when it parses the recipe, it constructs the hash of the tasks within the recipe. To do that it has to know about the hashes of the sources for fetch
florian has joined #yocto
goliath has quit [Quit: SIGSEGV]
<landgraf>
RP: Thank you for the explanation. My problem is not in the fact it fails, but in the fact it doesn't fail in some cases :) Anyway, I will create empty zip file to make bitbake in codebuild happy. hopefully will have time to investigate it further later.
<landgraf>
RP: found it! I have added this "feature" myself :( This particular recipe has special SRC_URI handling in case if it's being build under codebuild.
<RP>
landgraf: I don't understand enough about the issue to give a better answer :/
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
MattWeb82 has joined #yocto
steelswords has joined #yocto
<JaMa>
landgraf: what is "codebuild env"?
goliath has joined #yocto
Xagen_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tgamblin_ has joined #yocto
gsalazar has joined #yocto
tgamblin has quit [Ping timeout: 272 seconds]
<landgraf>
JaMa: AWS Codebuild.
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
xmn has joined #yocto
jmd has joined #yocto
<JaMa>
landgraf: is it cheaper or easier to use for OE builds than normal instances?
<JaMa>
I mean does it scale well for different CI jobs from 5s linter call (which can run on a VM in a toaster) to 24 hour "bitbake world" build (which should run on beefier node or might end with OOMK after a week)
<landgraf>
JaMa: Not really, it was done before.
<landgraf>
JaMa: *before I joined the project
<JaMa>
"You just specify the location of your source code and choose your build settings, and CodeBuild will run your build scripts for compiling, testing, and packaging your code." is the marketing BS which rarely works well :)
Xagen has joined #yocto
<landgraf>
JaMa: I cannot say I'm happy with codebuild. One of the first advices I've got then I joined the project and my build failed - RETRY, sometimes it happens :D But codebuild is not worst thing I worked with tbh...
<JaMa>
ok, thanks
<RP>
landgraf: I really don't like advice like that :(
xmn has quit [Quit: ZZZzzz…]
<landgraf>
RP: who does... the reason of failures was easy to fix. no retries since then :)
<RP>
JaMa: could you see if a newer setuptools resolves that ccache issue? I'm wondering if the newer release helps? I'm thinking reverting the upgrade may be an option if not...
<Saur>
RP: I am trying to figure out why AB is failing due to my systemd.bbclass change and hope you can offer some insights. I have started by trying to recreate the runtime failures. I have build core-image-full-cmline with poky-altcfg for qemux86-64 with and without my change applied, but bitbake core-image-full-cmdline:do_testimage succeeds in both cases. :(
<RP>
Saur: which PACKAGE_CLASSES did you try?
<RP>
Saur: I didn't really look into the specifics of the failures but if you're struggling to get to the bottom of them, I guess I'll need to...
<Saur>
ipk
<RP>
Saur: which should have reproduced it :/
<Saur>
RP: Yes, I thought so too. :(
<RP>
Saur: I'd note that the qemuarm64-alt build succeeded when all the others failed. I wonder why...
<RP>
Saur: when you apply your change, is the image rebuilding correctly? Did you try cleaning the image and retrying ?
<RP>
that would suggest another issue if so but I'm just thinking out loud with random ideas...
<Saur>
RP: Interesting. I thought they had all failed, which is why I started with them rather than the selftests where you said some failed and some succeeded.
<RP>
Saur: Perhaps the build was still running when I reported but I'd assumed it would fail given the others
xmn has joined #yocto
<Saur>
*nod*
<Saur>
Related to the selftests, what limitations are there on what a test can change in the configuration using write_config()? E.g., my tests modify DISTRO_FEATURES, can that somehow impact other tests running at the same time?
<RP>
Saur: tests are all run in their own build directories. The main constraint is they must not delete from sstate
<RP>
Saur: we do run tests in parallel but they're in their own builddirs for selftest
<Saur>
Ok, so changing DISTRO_FEATURES per test should not be a problem.
<RP>
no
jmd` has joined #yocto
<RP>
Saur: I guess the exception would be if the change didn't cause something to rebuild correctly
<RP>
i.e. the features change didn't change taskhashes when it should have
<Saur>
Yeah, but the tests add/remove systemd and sysvinit as DISTRO_FEATURES. It should be hard for those to not cause the right sstate to be used...
<Saur>
Btw, I tried copying the bbclasses.py file a number of time and permutating the order of the tests and then running them in parallel. Didn't give anything. :(
enok has joined #yocto
<Saur>
RP: As I am not to accustomed to the AB, is there some way to see all the builds that were triggered with my change applied?
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
enok has quit [Ping timeout: 246 seconds]
<Saur>
RP: Interesting. I ran the selftests on a Ubuntu host now, and there they fail (my previous runs were on my Fedora host). So apparently the failures were not random, but rather affected by the host. Now to investigate why...
<sudip>
thanks JaMa, I will add that commit for now
alessioigor has quit [Remote host closed the connection]
<Saur>
RP: After a selftest has failed, is the selftest.inc file that was used available somewhere?
BenBE has quit [Ping timeout: 246 seconds]
<RP>
Saur: if you're just running a single selftest you can comment out the deletion code or make it put a copy somewhere at he start of the test
<Saur>
ok
enok has joined #yocto
<khem>
JaMa: yeah churn nevertheless
fotte has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
<Saur>
RP: Found it. Calling read without arguments is apparently a bashism. Thus the tests failed on hosts with dash as /bin/sh.
<JaMa>
khem: I've found few more buildpaths issues (which might be triggered only when multilib is used) will try to find time to send patches next week
<khem>
JaMa: yeah that would be helpful, I am looking out for fixing the AB build ATM it has been broken for too long so other things are a bit lagging w.r.t meta-openembedded
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
jmd has joined #yocto
leon-anavi has quit [Remote host closed the connection]
enok has quit [Ping timeout: 272 seconds]
jmd has quit [Remote host closed the connection]
enok has joined #yocto
BenBE has joined #yocto
<moto-timo>
How do I run "-c devshell" in a multiconfig? bitbake -c devshell mc:product-foo:recipe-bar doesn't seem to be working (maybe it's a pyrex issue though...) it just drops me back to the original shell, not the devshell...
mvlad has quit [Remote host closed the connection]
mbulut_ has quit [Ping timeout: 265 seconds]
enok has quit [Ping timeout: 264 seconds]
olani- has joined #yocto
<RP>
khem: I'm not sure we want to take the numpy upgrade for 5.1, it seems lots of software isn't ready for that yet
MattWeb82 has quit [Ping timeout: 246 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]