<jclsn>
JPEW: I would like to use tmux too. Where can I change that? Seems like it defaults to screen
mbulut_ has joined #yocto
<dvergatal>
RP: BTW can you remind me the approach for tar you proposed so I could start implementing it?
<RP>
dvergatal: I'm trying to get the current release sorted, I don't really have the time to step you through that right now :(
<dvergatal>
RP: n/p at all I'm leaving on monday to germany so we can continue the subject after my comeback on next friday?
tnovotny has joined #yocto
jetm has quit [Server closed connection]
jetm has joined #yocto
florian_kc has joined #yocto
amitk_ has joined #yocto
amitk_ has quit [Remote host closed the connection]
varjag has joined #yocto
<kanavin_>
dvergatal, we have irc logs, so you can find it there. RP is stretched very thin, so I strongly recommend you never, ever ask him to commit time to your project.
zelgomer has quit [Ping timeout: 246 seconds]
zelgomer has joined #yocto
Schlumpf has quit [Quit: Client closed]
<dvergatal>
kanavin_: I know that there are irc logs and I can search for it, but I wanted to discuss the subject in details, and this is not just my project...
<kanavin_>
dvergatal, it's perhaps better suited to the oe-core mailing list
<dvergatal>
kanavin_: ok thx
slimak has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest47 has joined #yocto
Guest47 is now known as dmtkats
<dmtkats>
Hello, I have a question regarding ext sdk vs sdk and accessing the toolchain provided
<dmtkats>
Currently, I am using the basic sdk for development. This works fine, but is a hastle for updating. Ideally I would like to use the extensible sdk and have a mirror that is updated by the build server, then have the esdk do the updating
<dmtkats>
However, from what I can tell, the esdk expects the workflow to go through devtool. Ideally I would like to directly have access to the cross compiler so I can do targetted compilation of specific components of my project
<dmtkats>
Is there any way to get direct access to the toolchain for either a given recipe or in a similar way as it is exposed with the standard sdk? I know of devshell, but that isn't nice to integrate with an IDE or with build scripts
<kanavin_>
dmtkats, which version of yocto are you using?
<dmtkats>
kanavin_, I am using kirkstone atm
<dmtkats>
Thanks for the quick response :)
<kanavin_>
dmtkats, I think extensible sdk also allows direct toolchain access. If you want easy updates, there's now a 'direct SDK' but for that you need something newer than kirkstone (added last summer).
<kanavin_>
dmtkats, check out poky mickledore and play with it
<dmtkats>
ah nice! so I just need to update. That sounds promising, thanks!
<kanavin_>
dmtkats, adrianf is your man
<kanavin_>
he is heavily using all those things, I'm not
<dmtkats>
I will stick around for a while and see if adrianf has something else to add, thanks again :)
<jclsn>
Is there any way to make devshell use tmux instead of screen? I have tried to set OE_TERMINAL=tmux
<kanavin_>
adrianf has a private backport I think, not sure
lighteagle has joined #yocto
prabhakarlad has quit [Quit: Client closed]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
prabhakarlad has joined #yocto
ptsneves has joined #yocto
zhmylove has joined #yocto
Nixkerna- has joined #yocto
Nixkerna- has quit [Client Quit]
Tyaku has joined #yocto
<Tyaku>
Hello, I have a problem in the yocto build, this is not the first time I have it, and as I know that everytime I have this problem, I try things that force me to rebuild everything I come here to ask for help before broking my build ..
<RP>
dmtkats: we've certainly intended things to be usable like that, it probably does need better documentation
<Tyaku>
https://pastebin.com/G7smUmAg I have a package with a recipe "rpmsg-caipiteam-mod" in my meta. This package build a .c file (that is on the files of the package) and generate a module.
<Tyaku>
After I modify the .c file (which was in meta-caipiteam/recipes-kernel/rpmsg-caipiteam-mod/files/rpmsg-caipiteamn.c I get this error: package rpmsg-caipiteam-mod-1.0-r0.hub_mz_maquette_poseidom requires kernel-module-rpmsg-caipiteam-5.10.52-lts-5.10.y-az-p01+g9201024815f4, but none of the providers can be installed
<Tyaku>
*After I change the file and I restart a build.
<Tyaku>
Please did someone know: 1. Why I have this error after changing the .c file in the meta & build ? 2. How to fix it, without rebuilding everything.. ?
vladest has quit [Quit: vladest]
vladest1 has joined #yocto
vladest1 is now known as vladest
<l3s8g>
Tyaku: Is there perhaps more useful information in the logfile mentioned in line 14 of your pastebin?
rfuentess has quit [Remote host closed the connection]
<mcfrisk>
poky commit 10f38157a06 triggers lots of "Re-cloning" warnings for me. had an old typo in DL_DIR and fixed that by adding a symlink so that old and new builds can use the same cache. now things get re-cloned..
<mcfrisk>
I would like to be able to move DL_DIR around and not end up with a re-clone just because the path changed. In my case /download/downloads/
<RP>
mcfrisk: I didn't really like the complexity that patch adds :(
<RP>
mcfrisk: I'd consider the paths being "hardcoded" a bug to be honest
<RP>
mcfrisk: you could have an nfs share mounted in different locations
<mcfrisk>
RP: exactly. I would also expect DL_DIR cache to be relocatable, and that's one of the things I do to bootstrap build machines and workspaces; fetch download and sstate caches from some other machine
zpfvo has quit [Ping timeout: 260 seconds]
<PhoenixMage>
Is /sys/kernel/config/device-tree not a thing anymore? Pretty sure I got the right kernel config options but the only thing I get is pcie_ep in /sys/kernel/config
<PhoenixMage>
I am on a 6.4 kernel
Xagen has joined #yocto
zpfvo has joined #yocto
vmeson has quit [Ping timeout: 246 seconds]
Minvera has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
vmeson has joined #yocto
frieder has quit [Remote host closed the connection]
dacav has quit [Quit: leaving]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
vladest has quit [Ping timeout: 258 seconds]
<RP>
mcfrisk: I'd reply on list, see if JPEW has any ideas
<JPEW>
mcfrisk: Ah.... probably the --absolute-git-dir part?
<JPEW>
mcfrisk: Hmm, but it's running abspath on ud.clonedir also
<JPEW>
What's the actual message you get?
tnovotny has quit [Quit: Leaving]
pabigot has quit [Ping timeout: 245 seconds]
l3s8g has quit [Remote host closed the connection]
Vonter has joined #yocto
otavio has quit [Ping timeout: 240 seconds]
geoffhp has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
geoffhp has joined #yocto
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
slimak has quit [Ping timeout: 245 seconds]
linfax has quit [Ping timeout: 258 seconds]
zeddii has quit [Ping timeout: 248 seconds]
pabigot has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
zeddii has joined #yocto
florian has quit [Quit: Ex-Chat]
otavio has joined #yocto
amitk has joined #yocto
l3s8g has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Client Quit]
prabhakarlad has joined #yocto
zpfvo has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
nerdboy has quit [Ping timeout: 245 seconds]
<khem>
RP: yeah saw that ppc64 dnf issue is intermittent I wonder if it has some host influence while building some stuff. One difference for ppc64 is that our BASELIB is lib64 which matches some build host directory structure too so it might be exposing a latent problem too. Do we have the failing build around ?
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
prabhakarlad has quit [Quit: Client closed]
ptsneves has quit [Ping timeout: 246 seconds]
<RP>
khem: I'd think there should be one. I wonder if it is some flaky qemu emulation issue :/
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Joel48 has joined #yocto
<Joel48>
Moin! Where do I find the recipe source code after patching to check if my patch was applied? I'm trying to patch libusb and Yocto is not complaining but it doesn't look like my changes are making it in.
<rburton>
tmp/work/.../
<rburton>
if you add a .patch or .diff to SRC_URI, it's being applied
<rburton>
but you possibly added it to the wrong recipe
<Joel48>
rburton I'm using devtool to modify libusb1
amitk has quit [Ping timeout: 248 seconds]
<Joel48>
If I insert an error into the created bbappend file then bitbake complains
<khem>
RP: qemu is used quite a bit on ppc64le since there are some clouds offerring such machines so I would think qemu would be relatively ok but you have a point. On my debian12 container testsdk and testimage passed for core-image-sato always
amitk has joined #yocto
<khem>
after the rust fix I sent last night
gsalazar has quit [Ping timeout: 255 seconds]
<Saur>
Joel48: Use `bitbake-getvar -r libusb1 SRC_URI` to look at what Bitbake thinks the value of the SRC_URI variable is.
<Joel48>
Saur thanks!
<khem>
@Joel48 devtool creates an external source tree so check workspace/sources folder in topdir there will be a directory for libusb which is patched tree
<Joel48>
khem I think it's working now, checking...
<Saur>
Joel48: khem is right. If you have done `devtool modify libusb1`, but neither `devtool reset libusb1` nor `devtool finish libusb1 <layer>`, then the source in workspace/sources/libusb1 is what's being built and the SRC_URI does not matter.
<Joel48>
Oh, that's nice, actually! I didn't know that
<Joel48>
It's a stupid problem, thanks for listening! My Rust binary is static and built against a different libusb version. I'm gonna have to learn how to create Rust recipes.
slimak has joined #yocto
<RP>
khem: some builddirs should be there
<RP>
kanavin_: if you want to help with the autobuilder cancelled build problems, a script to query buildbot and work out if a build is active on a build directory would be really helpful - then we'd know what we can clean up
<RP>
halstead: I'm assuming you aren't looking at that?
olani has quit [Ping timeout: 246 seconds]
vmeson has quit [Ping timeout: 258 seconds]
vmeson has joined #yocto
Joel48 has quit [Quit: Client closed]
l3s8g has quit [Remote host closed the connection]
<Joel69>
bitbake doesn't show me where the parse error is, just complains
florian_kc has joined #yocto
amitk has quit [Remote host closed the connection]
<Joel69>
bitbake throws a parse error even if I just have "inherit cargo" in the file and nothing else. Well, it also complains about the missing LICENSE then but just gives the parse error if I add the license field.
ptsneves has joined #yocto
<rburton>
can you paste the actual error?
<Joel69>
ERROR: ParseError in usbmon: not a BitBake file | ETA: --:--:--
<Joel69>
ERROR: Parsing halted due to errors, see error messages above
<Joel69>
rburton just this
<Joel69>
There are no error messages above, though
<rburton>
i doubt that's what its parsing
<rburton>
move that file out of the layer and see what happens
<Joel69>
@rbur
<Joel69>
rburton everything works without that recipe but I'm trying to add it
<Joel69>
Oh... it doesn't. So the error is further upstream, or something like that. Must be in the meta-rust layer then. How do I troublshoot?
nerdboy has quit [Ping timeout: 246 seconds]
<Joel69>
Because I can't `bitbake rust-hello-world` (it's in the meta-rust layer) either. Same error so something that's introduced by the meta-rust layer.
<Joel69>
Is there a way to have bitbake show me where the error is exactly?
<rburton>
i presume you're using an old release as meta-rust isn't needed with recent releases
<Joel69>
What the hell?! I moved the usbmon recipe out and `bitbake rust-hello-world` but bitbake still complains about usbmon?!
<Joel69>
rburton I just checked out the layer. Are you saying that rust support (cargo, etc.) is built into some other yocto layer now?
<rburton>
yeah its in core
<Joel69>
rburton How do I figure out what file is throwing the parse error/
Marian32 has joined #yocto
<halstead>
RP, I'm not. I'm focused on getting new workers built and git.openembedded.iry moved.
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
<Marian32>
Hi, I'm trying to add image-buildinfo /etc/build. I added in local.conf INHERIT += " image-buildinfo " and is not working. Do you have any recomandations?
ptsneves has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
<RP>
halstead: that is fine, just double checking thanks
<adrianf>
dmtkats: We use it like that: Our build-servers share the sstate-cache whenever we merge something into the main branch. We have a script (which could be published, but is a bit specific to our infrastructure and our security stuff) to get the sstate downloaded to our personal machines. This allows to quickly build a firmware image and the related
<adrianf>
SDK with bitbake. The devtool ide plugin automatically configures the IDE (VSCode) to use the tool-chain provided by bitbake.
<kanavin_>
RP: I can look into that, perhaps tomorrow. I'm right now slightly worn out by the current upgrade patchset, which had a million consecutively uncovered issues before it got green verdict.
<abelloni>
RP: thanks, I was away today,
<RP>
kanavin_: I know the feeling :(
<RP>
kanavin_: I just wish I could work on my own patches even
<kanavin_>
RP: yeah, I got a bit ratty from that :-/ build after build after build, day after day. not good for mental well-being.
<kanavin_>
but I wanted to get it done because those are the trickier updates
<RP>
kanavin_: right, they are good to do. I do want to defer the useradd stuff though as the new dependencies are going to prove problematic. I know the horrors that lurk under the setscene dependencies