wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
<rburton>
mcfrisk: can you mail helpdesk@yoctoproject.org so the admins know but the infra was being hammered yesterday, so most likely more of the same and this is fallout from emergency workarounds
alessio has quit [Quit: alessio]
Daaanct12 has quit [Ping timeout: 252 seconds]
alessio has joined #yocto
Daanct12 has joined #yocto
rob_w has joined #yocto
<mcfrisk>
rburton: halstead replied to my report on yocto-infrastructure@lists.yoctoproject.org, things seem to be good. I'm trying to find the exact IP of server instance where we saw the failures
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 248 seconds]
belsirk is now known as rfuentess
ptsneves has joined #yocto
<rburton>
cool
mbulut has quit [Ping timeout: 252 seconds]
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
florian has quit [Ping timeout: 252 seconds]
Xagen has quit [Ping timeout: 268 seconds]
florian has joined #yocto
Jones42 has joined #yocto
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
Daanct12 has quit [Ping timeout: 244 seconds]
florian has quit [Ping timeout: 252 seconds]
Daanct12 has joined #yocto
eduter has quit [Quit: Client closed]
eduter has joined #yocto
florian has joined #yocto
enok has joined #yocto
rfuentess has quit [Remote host closed the connection]
florian has quit [Ping timeout: 248 seconds]
florian has joined #yocto
rber|res has quit [Remote host closed the connection]
Xagen has joined #yocto
<Jones42>
we're using the local fetcher (file://) with subdir=${S}/... to add our devicetree to the kernel sources. Now we'd like to (conditionally) apply a patch to that file, but do_patch complains because the file is not in the index. Is there a different way to accomplish that?
<rburton>
i suspect you're patching wrong in that case
alessio has quit [Ping timeout: 265 seconds]
Guest74 has joined #yocto
Guest17 has joined #yocto
<Guest74>
Hello!,
<Guest74>
i'm currently building an image for a x86 platform (with the meta-intel bsp / machine set to intel-skylake-64).
<Guest74>
This is working without a problem, but it seems that the TARGET_ARCH variable is set to x86 and not x86_64.
<Guest74>
How can i fix this?
florian has quit [Ping timeout: 248 seconds]
<Guest17>
I am trying build yocto for TI omap138. I am facing issue of tool chain
<mcfrisk>
should meta-arm just filter out "failed to find screen to remove" for now? was there an open bug for this?
florian has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
florian has quit [Ping timeout: 260 seconds]
<mcfrisk>
RP: sent a patch to meta-arm to ignore this screen removal error for now
<RP>
mcfrisk: thanks, not sure about any bug open or not
Guest74 has quit [Quit: Client closed]
<usvi>
can I apply patches on top of python modules coming from pypi / setuptools3 ?
<RP>
khem: I merged that bitbake change so we need the meta-oe patch
<jonmason>
RP: known issue....
<jonmason>
fvp-base is broken because uninative update (which is breaking more meta-arm CI entries). but I'll put this as the one to look at after that
<RP>
jonmason: ok, thanks. I wasn't sure if it was being worked on
<RP>
jonmason: what did the uninative update do? :/
<jonmason>
RP: fvp binary is no longer running
<jonmason>
since it's a precompiled binary, probably some hard req for something
<jonmason>
Guest17: are you trying meta-ti on git.yoctoproject.org? because that toolchain seems ancient
florian has joined #yocto
florian_kc has joined #yocto
<RP>
jonmason: hmm, right :/
davidinux has quit [Quit: WeeChat 4.3.1]
<LetoThe2nd>
zeddii: sorry to poke you again, but to bluntly just test meta-virts podman facilities, which image+machine+distro combo should I go for? Is that documented somewhere?
prabhakalad has quit [Quit: Konversation terminated!]
rob_w has quit [Remote host closed the connection]
enok71 has quit [Ping timeout: 260 seconds]
ptsneves has quit [Quit: ptsneves]
Guest17 has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
<rburton>
khem: can you push the gitpkgver fix in meta-oe please
<Jones42>
I think do_patch fails when applying a patch to a file that is not under version control. Our patch is fine, but since we add the file to be patched via file://...;subdir=${S}/... , it's not in the git index, so 'git am' fails...
<rburton>
Jones42: ah the kernel might be more "fun"
jpuhlman has quit [Ping timeout: 260 seconds]
<Jones42>
rburton: ah... so there's no easy solution I guess? Then we'll have to default to using two full dts files. Not nice, but will do.
jpuhlman has joined #yocto
<JaMa>
rburton: khem: the one in master-next doesn't seem to work, is there a different version of it?
<JaMa>
libusbmuxd_2.1.0.bb
<JaMa>
bb.data_smart.ExpansionError: Failure expanding variable GITPKGVTAG, expression was ${@get_git_pkgv(d, True)} which triggered exception AttributeError: 'dict' object has no attribute 'name'
<JaMa>
with it applied locally
Tyaku has joined #yocto
<Tyaku>
Hello, Did someone know if there is a watchdog that can be enabled during the boot ? We have the "watchdog" package but it seems to work only once the system is started (as this is an application).
<RP>
JaMa: I must have messed the patch up :(
<Tyaku>
I'm talking about it because I have a kernel driver (esp_hosted_ng) that can freeze the kernel sometimes
<JPEW>
Tyaku: Most SoCs have some sort of built in hardware watchdog, but it will depend on your hardware how it's enabled
enok has joined #yocto
<RP>
JaMa: new version sent, sorry. Not sure what happened to the original
<JaMa>
RP: np and thanks!
<rburton>
Tyaku: systemd has integrated watchdog support if you use that and have the hardware support
<Tyaku>
JPEW: We have a PMIC that is configured with: compatible = "dlg,da9062-watchdog"
<Tyaku>
But doesn't seems to be triggered, since 13 minutes (my linux startup sequence is frozen since 13 minutes due to a driver that is taking CPU) (maybe)
GillesM has joined #yocto
<Tyaku>
Also HW timer dont works "alone" it requiere some "software" to enable it at some point (when ? on u-boot ? when systemd start to start userspace application ? when systemd finished to start userspace application ?). It also require some "software" to refresh it
<khem>
but I am sure world build will reveal more failures
Kubu_work has joined #yocto
eduter has quit [Quit: Client closed]
jmiehe has quit [Quit: jmiehe]
Guest17 has joined #yocto
<JaMa>
gcc-15 seems even more mem hungry than gcc-14 was will probably need to lower -j for nodejs and chromium even more :/
florian_kc has quit [Ping timeout: 248 seconds]
florian has quit [Quit: Ex-Chat]
Guest17 has quit [Quit: Client closed]
<JaMa>
RP: for PACKAGECONFIG_CONFARGS in cargo, so you're saying that recipes aren't allowed to use PACKAGECONFIG at all if they want to use it for RUSTFLAGS and not cargo flags?
<JaMa>
RP: I don't know much about cargo and rust, but I don't think you can achieve the same with cargo
<RP>
JaMa: I think I misunderstood what you were saying. I find the "story" commit message approach you use hard to follow at times :/
<RP>
JaMa: We probably should revert
leon-anavi has quit [Quit: Leaving]
enok has quit [Ping timeout: 248 seconds]
<RP>
JaMa: replied on list
* RP
feels his "failure" rate is too high on things atm :(
<JaMa>
RP: sorry about that, we can wait a bit for the autor or original author to reply as I don't have many rust recipes to see how other people use it
<JaMa>
RP: thanks
<RP>
JaMa: I'm not a rust expert either :/
<JaMa>
I've found the original review where we're used this and the original syntax someone wanted to use was: