<ecdhe>
My vendor's u-boot recipe depends on the dtc-native package. It works when dtc 1.4.5 is supplied (the default back in sumo.) Then I added a recipe that requires dtc (>= 1.5.0). When I added a recipe for dtc v1.5.0, the u-boot recipe breaks.
<ecdhe>
Can I build an image that depends on two different versions of dtc-native?
ahs3 has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
prabhakarlad has quit [Ping timeout: 256 seconds]
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 256 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
jclsn7 has joined #yocto
jclsn7 has quit [Quit: Ping timeout (120 seconds)]
jclsn7 has joined #yocto
jclsn7 has quit [Ping timeout: 250 seconds]
fitzsim has quit [Read error: Connection reset by peer]
jclsn7 has joined #yocto
amitk has joined #yocto
fitzsim has joined #yocto
ahs3 has joined #yocto
geoffhp has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
vladest1 has joined #yocto
vladest has quit [Remote host closed the connection]
<landgraf>
RP: oh. the test is working now. probably example.com was not accessible yesterday for some reason :/
<landgraf>
adding second URI to ONNECTIVITY_CHECK_URIS should work (to not rely solely on example.com)
mckoan|away is now known as mckoan
<mckoan>
landgraf: that's a frequest problem. For that reason we always add CONNECTIVITY_CHECK_URIS = "https://www.google.com" in local.conf
<mckoan>
s/frequest/frequent
mvlad has joined #yocto
<mckoan>
AKA "frequently requested to be solved" = frequest (TM) :-D
olani has quit [Ping timeout: 240 seconds]
lucaceresoli has joined #yocto
ex-bugsbunny has joined #yocto
<landgraf>
well. the question is "all CONNECTIVITY_CHECK_URIS should be available" or "some CONNECTIVITY_CHECK_URIS should be available". Current logic is "all", changing to "some" is easy fix in the sanity.class
<landgraf>
as far as default value now is single "example.com" changing to "some" and "example.com google.com yoctoproject.org" should not affect users with default setting (or user who use "single" host) but there're may be users who relies on "all must be available"
kanavin has quit [Quit: Leaving]
kanavin has joined #yocto
zpfvo has joined #yocto
kroon has joined #yocto
<qschulz>
ecdhe: just create a new dtc-old_1.4.5.bb and put dtc-old-native in your DEPENDS
leon-anavi has joined #yocto
goliath has joined #yocto
Schlumpf has joined #yocto
florian_kc has joined #yocto
<RP>
landgraf: the fallout from testing that patch is fairly bad :(
<RP>
landgraf: bitbake-selftest failures, world build failures and a bug in devtool at least (see the swat list email I sent)
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
Rolle has joined #yocto
Rolle has quit [Client Quit]
Rolle79 has joined #yocto
<Rolle79>
I have a question specifically about the cmake recipe in openembedded-core, not sure if this is the right place to ask
prabhakarlad has joined #yocto
<qschulz>
Rolle79: only asking the question will tell us if it's the right place to ask it :)
GNUmoon has joined #yocto
florian has joined #yocto
florian_kc has quit [Read error: Connection reset by peer]
<Rolle79>
So ,the default supplied toolchain OEToolchainConfig.cmake, is as I can see it generally problematic. It relates to the cached variables with the FORCE option set (CLFAGS, LDFLAGS etc). The toolchain file is re-run every time cmake re-runs, for example when we change in our local CMakeLists.txt file. Having the FORCE variable set, in combination
<Rolle79>
with using ENV() to pick up CFLAGS etc, means that if we happen to re-run cmake in a shell that no longer have the environment from Yocto sourced, the flags will suddenly be overwritten, this time with (perhaps) other and faulty flags. I get that I can just write my own toolchain file, but I wonder if there is any motivation for this. Usually,
<Rolle79>
cmake toolchain files are more explicit and looks a lot more like the environment file that is also default supplied with Yocto.
<Rolle79>
So, the default supplied toolchain OEToolchainConfig.cmake, is as I can see it generally problematic. It relates to the cached variables with the FORCE option set (CLFAGS, LDFLAGS etc). The toolchain file is re-run every time cmake re-runs, for example when we change in our local CMakeLists.txt file. Having the FORCE variable set, in combination
<Rolle79>
with using ENV() to pick up CFLAGS etc, means that if we happen to re-run cmake in a shell that no longer have the environment from Yocto sourced, the flags will suddenly be overwritten, this time with (perhaps) other and faulty flags. I get that I can just write my own toolchain file, but I wonder if there is any motivation for this. Usually,
<Rolle79>
cmake toolchain files are more explicit and looks a lot more like the environment file that is also default supplied with Yocto.
florian_kc has joined #yocto
<qschulz>
Rolle79: just use bitbake -c devshell my-recipe to have everything setup correctly
<qschulz>
or build an SDK and use it?
florian has quit [Ping timeout: 245 seconds]
<rburton>
RP: fwiw, ten of our jobs in the overnight CI failed (out of about 50)
<rburton>
with example.com failure
<Rolle79>
I build an SDK and use it now, but I dont want devs to have to think about sourcing the environment file. For our initial project setup, this is done through a script, but after that I want the devs to be able to build in their native shell without dependence on env vars
coldspark29[m] is now known as jclsn[m]
<jclsn[m]>
Is anyone else using Kitty here and also having issues with bitbake?
<kroon>
Rolle79, im no cmake expert but cant you add a cmake target that just sources the env. script and then runs cmake again with the actual targets ? i did that with a make project
alessioigor has joined #yocto
GNUmoon2 has joined #yocto
alessioigor has quit [Quit: alessioigor]
florian_kc is now known as florian
alessioigor has joined #yocto
<Rolle79>
The problem is that I don't know where the SDK when cmake runs, as those were picked up via env and are now lost. So i can find the env script then. It also feels like a bit of a hack
<Rolle79>
I can get around it by creating my own toolchain file, I was mostly interested in the motivation behind this
GNUmoon has quit [Ping timeout: 276 seconds]
mihai has quit [Quit: Leaving]
<pasherring>
kroon, so am I not expert, but, I think you cant do that, any env changes made from within cmake will vanish as the process terminates
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd>
yo dudX
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
<pasherring>
If sourcing a script is really problematic, would sourcing it when session starts be an option?
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
<pasherring>
Rolle79, another option would be to patch the env script to change the shell prompt line to something more expressive. I.e., adding some PS1="\e[0;31m[\u@YoctoEnvActivated:\W]\$ \e[m " or colorize as you like
kriive has quit [Ping timeout: 250 seconds]
kriive has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
Rolle79 has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
ekathva_ has joined #yocto
ekathva_ has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
kriive has quit [Remote host closed the connection]
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
kroon has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<landgraf>
rburton: "simplified" version sent (how can I "obsolete" old patch btw? )
<rburton>
you you mark it as obsolete in patchworks, but i don't think anyone actually pulling the patches use that
<rburton>
I do think we should pull a specific page instead of just / as that's 300K+ of wordpress
<rburton>
RP: thoughts on the connectivity thread?
<rburton>
i say we get halstead to create a tiny page on yoctoproject.org/connectivity.html or something which is statically served
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
rburton: consdering that we had down times on git servers already, is it wise?
zpfvo has joined #yocto
<rburton>
qschulz: at least if our servers go down we can talk to our admins
<qschulz>
rburton: ah wait, are you considering a Yocto wide change or just for the autobuilders?
<rburton>
change to oe-core
<rburton>
everyone of my last 10 CI pipelines failed because some of the jobs fails to ping example.com
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<landgraf>
small one-word static page on yp.org should be better option
<qschulz>
rburton: is it pinging or wget?
<rburton>
wget
<rburton>
the fetcher runs on a url
<qschulz>
rburton: ping 8.8.8.8 or 1.1.1.1 in that case I guess
<rburton>
the point is to verify that the fetcher will work
<qschulz>
rburton: yeah, trying to think of a stupidly small always-on page we don't need to maintain :)
<landgraf>
wget
<rburton>
so it does a https: fetch to verify certificates and proxies
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian has quit [Read error: Connection reset by peer]
florian has joined #yocto
<qschulz>
rburton: yocto.github.io with a static page :p ?
Rolle79 has joined #yocto
<Rolle79>
pasherring Its not extremely problematic, just a bit annyoing
<Rolle79>
Especially as the build often succeeds anyway, but with different options set (which is not obvious if you dont compile it with high verbosity)
<landgraf>
qschulz: github is not accessible from anywhere (same as google) unfortunately :/
<qschulz>
landgraf: it was a joke :) github.io is probably down more often than example.com :)
<rburton>
for sure :)
rob_w has joined #yocto
* landgraf
remembers one day when 8.8.8.8 and yandex.ru both went down it triggers massive downtime across all Russian ISV (they use 8.8.8.8 as primary and yandex.ru as secondary for hearbeat so they started switching between uplinks)
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
rob_w has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
florian has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
florian has joined #yocto
florian has quit [Read error: Connection reset by peer]
florian has joined #yocto
Dracos-Carazza has quit [Ping timeout: 256 seconds]
lucaceresoli_ has joined #yocto
lucaceresoli has quit [Ping timeout: 252 seconds]
argonautx has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Rolle79 has quit [Quit: Client closed]
<RP>
rburton: replied
florian has quit [Read error: Connection reset by peer]
<RP>
landgraf: I have updates for that fetcher series that fix some of the issues
Tokamak has joined #yocto
<RP>
(I updated master-next)
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
TommyD has quit [Ping timeout: 240 seconds]
marc2 has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
TommyD has joined #yocto
zpfvo has joined #yocto
marc2 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<Saur>
RP: I'm not sure you can help me or that I can even describe the issue, but I'll give it a try because I've a weird problem related to the sstate cache of which I cannot make heads or tails. The other day I backported the changes I made for package.bbclass to our layers (based on Hardknott). This of course caused all RPMs to be recreated, and somewhere there something odd happened for one of the packages. Package foo (2.6.6) has an execut
<Saur>
able linked to libbar provided by the bar (2.0.3) package. Dnf now fails because it says there is no provider for libbar.so.1 which foo needs, which is fully understandable because the version that the bar package provides is libbar.so.2. I've tried following the siginfo files for foo_2.6.6:do_package_write_rpm and it eventually depends on bar_2.0.3:do_package. So how can I have a binary in foo_2.6.6 that must have been built with bar_1.x
<Saur>
.y (which provided the libbar.so.1) when everything indicates that it should have been built with bar_2.0.3 (and thus should have been linked to libbar.so.2)?
mckoan is now known as mckoan|away
<RP>
Saur: is hash equivalence enabled?
<Saur>
RP: Hmm, this is Hardknott based on poky so it seems it is. But we have no global hash server, only a global sstate cache.
<RP>
Saur: I would worry about that in this context :/
ex-bugsbunny has quit [Remote host closed the connection]
<Saur>
RP: How can that lead to that the current state having a foo executable linked to libbar.so.1 paired with a libbar package that provides libbar.so.2? Even with the hash server, it should not have been possible for it to replace the hash for a bar package with libbar.so.2 with a hash for a bar package with libbar.so.1 as they most definitely would have equivavlent output.
<Saur>
would not*
<RP>
Saur: I worry that some of the recent bugs we've found in hashequiv could allow such things to happen. It would depend exactly how the two packages depend on each other and whether it was an indirect or direct dependency
<Saur>
The foo recipe has DEPENDS = "bar"
<RP>
so that probably shouldn't be possible
<RP>
Saur: another way this can happen is broken makefiles
<RP>
something reran but didn't rebuild when it should have done if you don't use clean workdirs and reuse a tmpdir a lot
<halstead>
rburton: Easy enough to add yoctoproject.org/connectivity.html. That's backed by AWS us-west-2.
<RP>
halstead: could you do that please and we'll tweak the urls. It is breaking things for people
<halstead>
RP: I'm about to start making uninative again. I already tagged so I'm going to have to delete and push new tags. Will require a forced update from end users which I try to avoid.
<RP>
halstead: right, sorry about that. It was unfortunately borken. We could just skip to a new version?
<halstead>
RP: Your choice. Normally I'd retag and break some people's CI. Skipping to 3.6 would avoid that.
<Saur>
RP: Hmm. But wouldn't the update from bar_1.x.y to bar_2.0.3 trigger a clean of foo?
<RP>
halstead: should be fine, thanks
<RP>
Saur: it will not. depending on what changed it might just rerun do_compile or do_install or simply rerun do_package
<halstead>
RP: For the new perf workers I'm going with debian 11 and almalinux 8. Does that work for you?
<RP>
halstead: sounds good to me
<Saur>
Hmm, ok. Let's see if I can recreate that by downgrading bar, rebuilding foo and then upgrading bar again. Interesting...
<Saur>
(We don't change the major version of libs very often, so it might just have been a coincidence that it happened at about the same time I updated package.bbclass...)
<RP>
rburton: landgraf: I've sent a patch to update to the above url from michael
TommyD has quit [Remote host closed the connection]
* Ch^W_
rolls up his sleeves and tries to figure out why variables defined in the distro conf are not available inside rootfs-postcommands.bbclass during do_rootfs()
lexano has quit [Remote host closed the connection]
<Saur>
RP: A little follow up on my sstate cache problem. It is apparently the sstate:bar:...:2.0.3:..._populate_sysroot.tgz tar ball that contains old versions of the files (from more than two weeks ago), while the corresponding sstate:bar:...:2.0.3:..._package_write_rpm.tgz has the correct new files. So even if I rebuild foo, it still links with the old files, and dnf still fails. Thankfully a trivial whitespace change to a variable in the bar
<Saur>
recipe seems to solve the problem.
<Saur>
Now if I could only understand how this problem could be triggered by modifying package.bbclass...
lexano has joined #yocto
<ziga_>
I managed to detect my I2C device in the Linux. It is a touch controller "st1232". I wrote my device tree so that it put him on the appropriate I2C bus. But touchscreen does not respond when I use my finger. Is it possible that I need any library? Any kernel option maybe? Has anyone got any idea?
<RP>
Saur: identifying a pattern helps but I'm not sure what could/would cause that. Changing packaging would only cause packing to rerun, why the populate_sysroot is stale, I don't know :/
<rburton>
RP: awesome
dgriego has joined #yocto
<Saur>
RP: I am quite baffled by this. However, since I cannot rule out interaction by having the hash server enabled, but without having a global hash server I think we are better off disabling it (at least until we have a global server running). Is it enough to set BB_SIGNATURE_HANDLER = "OEBasicHash" in our configuration?
<rburton>
ziga_: so many questions: how is the touchscreen hooked up to the input subsystem, does evdev or libinput see it, what app are you using to see responses, etc.
* rburton
-> dinner
<ziga_>
@rburton Touchscreen is hooked to the system using I2C. How can I check if evdev / libinput see it?
florian has quit [Ping timeout: 240 seconds]
Thorn has quit [Ping timeout: 250 seconds]
florian has joined #yocto
Thorn has joined #yocto
lucaceresoli has quit [Quit: Leaving]
argonautx has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
mvlad has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
alejandrohs has joined #yocto
Minvera has joined #yocto
nateglims has joined #yocto
florian has quit [Ping timeout: 252 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
nateglims has quit [Ping timeout: 256 seconds]
nateglims has joined #yocto
Minvera has quit [Quit: Leaving]
bradfa has quit []
amitk_ has quit [Ping timeout: 256 seconds]
florian has joined #yocto
Subaudible has quit [Remote host closed the connection]
Pan5ky has joined #yocto
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]