seninha has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
xmn has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
<LetoThe2nd>
yo dudX
manuel_ has joined #yocto
mvlad has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
manuel_ has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
florian has joined #yocto
manuel_ has joined #yocto
<jclsn>
Morning
<jclsn>
How to make sure files get rebuilt if the deploy folder is gone?
<jclsn>
We have an issue that when we delete u-boot.imx from the deploy folder, it doesn't get automatically rebuilt if the sstate-cache is still present
<kanavin>
jclsn, you are not supposed to write directly to deploy. It needs to be placed to sstate, and unpacked to deploy from there.
vladest has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
<jclsn>
kanavin: Hmm okay have to check my recipes
nemik has joined #yocto
<kanavin>
jclsn, there are examples in meta/ how to do this properly, I don't have a specific lik handy. look for DEPLOYDIR.
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nucatus has quit [Remote host closed the connection]
nemik has joined #yocto
nucatus has joined #yocto
<jclsn>
kanavin: do_deploy[nostamp] did the trick
<jclsn>
Dirty workaround, but well
florian has quit [Ping timeout: 246 seconds]
<qschulz>
jclsn: don't remove files from the deploy directory?
goliath has joined #yocto
<qschulz>
jclsn: removing the whole tmp directory is safe but removing some files by hand isn't
<jclsn>
qschulz: The error also occurs when the whole tmp is deleted
<jclsn>
We encountered this in our pipeline
<jclsn>
forcing u-boot do be deployed every time fixes it
vladest1 has joined #yocto
vladest has quit [Ping timeout: 260 seconds]
vladest1 is now known as vladest
<qschulz>
jclsn: well, probably your deploy task is doing something it shouldn't
<qschulz>
like kanavin said
<jclsn>
qschulz: It is just copying u-boot.imx from the workdir to the deploy dir
<qschulz>
jclsn: which deploy dir
<jclsn>
It is a recipe for copying our pre-built bootloader from the Android toolchain. It will be deprecated soon anyway
<jclsn>
tmp/deploy/images/machine
<qschulz>
we have DEPLOY_DIR, DEPLOYDIR, DEPLOYDIRIMAGE
<qschulz>
jclsn: no, that's the final deploy directory but it is not where recipes are supposed to install, hence the question
<qschulz>
what is the path you put in your deploydir
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<rburton>
JaMa: only in the sense that it would be interesting to look at when adding rust-bin recipes to oe-core, but i'd want rust-bin recipes in core to be effectively identical to the source built ones
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
kanavin has quit [Ping timeout: 268 seconds]
<JaMa>
rburton: I've noticed it because someone else added it to our build (probably because of need of newer rust than what's in kirkstone) and somehow it doesn't seem to respect crates in SRC_URI (or at least is affected by https://github.com/rust-lang/cargo/issues/9390) so it tries to access network in do_compile
<rburton>
yeah, i suspected it was sub-optimal
* JaMa
testing kanavin's cargo-update-recipe-crates as well
kanavin has joined #yocto
<rburton>
ha speak of the devil ;)
<rburton>
JaMa: a review of that would be appreciated
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<JaMa>
rburton: I plan to, but for now trying to figure out if the issues are in bbclass limitations or just weirdness of solana build infra
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
<JaMa>
kanavin: ^ that was about cargo-update-recipe-crates.bbclass, the only review comment for now is extra space before \n in generated .inc file and preferrably using 4 spaces for indentation instead of 8
<JaMa>
once I know more I'll reply to list
<kanavin>
JaMa, I couldn't figure out what the right amount of backslashes should be to avoid the extra space
<kanavin>
\ \\ \\\ \\\\ \\\\\ did not work, then I gave up
<JaMa>
I see, I've just noticed git am complaining about trailing spaces
<kanavin>
JaMa, I think I also missed what you said, brief internet outage here
<JaMa>
the weird solana case is that we have a recipe where S points to https://github.com/solana-labs/solana-program-library/tree/master/token/cli, but the Cargo.lock files are in git root and other subdirectories, so the bbclass doesn't find them (but I need to figure out if cargo itself would find them - I have very little experience with rust/cargo)
nemik has quit [Ping timeout: 252 seconds]
<JaMa>
10:58 < JaMa> rburton: I've noticed it because someone else added it to our build (probably because of need of newer rust than what's in kirkstone) and somehow it doesn't seem to respect crates in SRC_URI (or at least is affected by https://github.com/rust-lang/cargo/issues/9390) so it tries to access network in do_compile
<JaMa>
10:59 < rburton> yeah, i suspected it was sub-optimal
<JaMa>
11:00 * JaMa testing kanavin's cargo-update-recipe-crates as well
<kanavin>
JaMa, we probably need ability to point to a non-standard location for Cargo.lock. I would not want to traverse all of $WORKDIR looking for it
nemik has joined #yocto
<JaMa>
in cargo.bbclass I've seen CARGO_SRC_DIR ??= "" for Cargo.toml, maybe something similar for Cargo.lock as they might not be in the same directory (at least in this solana case)
<kanavin>
JaMa, would prefer CARGO_LOCK_SRC_DIR ??= "${S}"
<kanavin>
otherwise looks good
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
seninha has joined #yocto
kovalevsky has joined #yocto
kovalevsky has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 248 seconds]
zpfvo has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
vladest has quit [Ping timeout: 268 seconds]
<xcm>
hello. i've rebuilt my image and i'm trying to use bmap as before, but i get "bmaptool: ERROR: cannot set image size to 92547102 bytes, it is known to be 439562240 bytes (419.2 MiB)". i've tried `bitbake -c clean my-image` but it didn't help
<qschulz>
xcm: is your image creating a bmap file or are you attempting to use a bmap file from an older image?
<xcm>
qschulz: i'm using the generated symlinks (.wic.bmap and .wic.bz2)
<qschulz>
xcm: are the files pointed at by the symlinks up-to-date?
<qschulz>
(I'm trying to check if you are not missing an IMAGEFSTYPES)
<xcm>
apologies, my bad. bmap is for some reason not playing nicely with zsh's proc. substitution. i'm using that to flash files built on a remote server
<xcm>
but if i scp first, then it works
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
seninha has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Schlumpf has joined #yocto
<tlwoerner>
is there a way to get the HOST_PREFIX of the target in a -native build?
<rburton>
no
<rburton>
on purpose
<qschulz>
tlwoerner: this would make the native build target specific which is probably not what you want
<rburton>
native is target agnostic
<tlwoerner>
yea... i know it sounds crazy
<tlwoerner>
there's a native tool called "ldr" that is needed as part of the final steps of building u-boot for a specific SoC
<qschulz>
tlwoerner: but that would be done in the u-boot recipe?
<tlwoerner>
but in the u-boot Makefile the tool is invoked as $(CROSS_COMPILE)ldr
<qschulz>
where you'd depend on ldr-native?
<qschulz>
tlwoerner: you could use flags or environment variables to pass the info to ldr at runtime?
<tlwoerner>
so in the U-Boot Makefile it needs to call the tool as arm-oe-linux-gnueabi-ldr or arm-poky-linux-gnueabi-ldr ... etc depending on your setup
<tlwoerner>
if it were a non-native recipe i could simply install the tool as ${D}${bindir}${HOST_PREFIX}ldr, but that doesn't work
<qschulz>
tlwoerner: gcc does that, so maybe look into it
<tlwoerner>
qschulz: yes, the u-boot recipe DEPENDS on the ldr-native recipe, that plumbing is fine, it's that i have to rename the final binary in a target-specific way
<tlwoerner>
qschulz: oh true, thank
<tlwoerner>
s
<qschulz>
but if ldr is capable of doing multiple architectures without recompilation, then a patch for the Makefile to use ldr without the prefix and passing some variable storing the target architecture to it would be probably smarter?
<rburton>
tlwoerner: two solutions. 1) if ldr is actually target agnostic, install as ldr and use a variable to set eg LDR=ldr. 2) build ldr as a cross, not a target, recipe.
sakoman has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<tlwoerner>
qschulz: rburton: thanks, i think whoever wrote the ldr tool was confused about what the $(CROSS_COMPILE) is for (versus --build and --host configure arguments)
<tlwoerner>
i don't think that it works the way, say, gcc does (run on a machine and generate code for various other machines)
zpfvo has joined #yocto
vladest has joined #yocto
nucatus has quit [Remote host closed the connection]
vladest1 has joined #yocto
nucatus has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
vladest1 is now known as vladest
xmn has joined #yocto
<mischief>
is there a way to disable mirrors (eg the yocto source mirror) for only some recipes?
<mischief>
i just realized we've been leaking SRC_URIs :|
<rburton>
sounds like you want to unset PREMIRRORS. note that recent releases don't use PREMIRRORS for anything but gcc/binutils out of the box.
goliath has quit [Quit: SIGSEGV]
<mischief>
rburton: does PREMIRRORS cause a fetch of git archive tarballs for git SRC_URIs?
<rburton>
yes
<rburton>
PREMIRRORS then SRC_URI then MIRRORS
<tlwoerner>
adding EXTRA_OEMAKE += "LDR=ldr" did the trick
<rburton>
see poky 5fe3689f4f177eb918e1d8e1f5f1f3c5376aa073 and 61d38cd3a29036309514c0e5da0aab60e938d185 for recent changes
<mischief>
in this case, SRC_URI was failing, so maybe it fell back to mirrors after that?
<rburton>
yes
<tlwoerner>
in theory the proper fix would be to remove the $(CROSS_COMPILE) from u-boot's Makefile
<tlwoerner>
thanks again qschulz and rburton
<rburton>
mischief: you should be able to set MIRRORS="" in the recipe if you want to avoid hitting the mirrors
<mischief>
some genius in our work make a git branch named e.g. `foo`, went on to delete it, then made `foo/bar`
<mischief>
and git did not like that
kscherer has joined #yocto
seninha has joined #yocto
vladest has quit [Ping timeout: 252 seconds]
manuel_ has quit [Ping timeout: 246 seconds]
ecdhe_ is now known as ecdhe
<vvn>
Would you rather support various customers configurations (e.g. some using sound or not, this or that software stack, ...) via a single company distro and multiple customer images, or multiple customer distros?
kscherer has quit [Remote host closed the connection]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
kscherer has joined #yocto
<kayterina[m]>
hello. If I append SRC_URI:append:A for a patch to apply only on machine A, do I also append a task for the patch to apply?
<rburton>
no
<vvn>
no
<LetoThe2nd>
noooooooooo
<kayterina[m]>
ok...so I must have a syntax error....
goliath has joined #yocto
<qschulz>
vvn: you're going to be limited at one point with images anyway, so I'd go with distros
alessioigor has quit [Quit: alessioigor]
Schlumpf has quit [Quit: Client closed]
<vvn>
qschulz: yeah that's where I'm struggling again, a distro per "field" seems very flexible but a PITA to maintain, especially since it encourages one to tweak features and thus impact packages configuration (and make the build more complex to manage)
prabhakarlad has quit [Ping timeout: 244 seconds]
prabhakarlad has joined #yocto
<rburton>
kayterina[m]: don't forget that append doesn't add whitespace so you'll want to :append = " file://...."
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 250 seconds]
jmiehe has joined #yocto
zpfvo has quit [Quit: Leaving.]
jmiehe has quit [Quit: jmiehe]
kscherer has quit [Quit: Konversation terminated!]
rber|res has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<JaMa>
vvn: that really depends on how different the configurations are and also how many of these configurations you need to maintain @LGE we have 4-5 DISTROs and 30+ different images and it's pain to maintain, because everybody thinks their configuration is "special" and needs special handling, so they don't even agree on the same base version of e.g. gstreamer
<JaMa>
and instead of nice consolidated platform usable by many you end with random mix of these special needs glued together with a lot of glue to keep it buildable most of the time
Vonter has quit [Quit: WeeChat 3.7]
<rburton>
khem: do you plan on making a langdale branch for meta-clang shortly, or only when needed?
Vonter has joined #yocto
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
<vvn>
JaMa: my point exactly, thanks for your feedback. My situation kinda looks like yours. Multiple distros seems intuitive to e.g. remove alsa pulseaudio for fields not using sounds, but at the same time you can't (especially developers) use and share the same built binaries.
odra_ has quit [Quit: Leaving]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
elfenix|cloud has joined #yocto
sakoman has quit [Quit: Leaving.]
vladest has joined #yocto
florian_kc has joined #yocto
sakoman has joined #yocto
<jonmason>
tlwoerner: could you see "notes" if I add them to my proposal? I think my proposal could be 15 mins, or 30 if I stretch it, thus the notes
manuel_ has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Minvera has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<tlwoerner>
jonmason: i'm not organizing this YPS for "reasons" (that i'm now happy to share, but which are too long to share over irc)
<jonmason>
tlwoerner: sorry, I just assumed
<LetoThe2nd>
jonmason: you can shoot over to me
<jonmason>
LetoThe2nd: so, can you see "notes" of the CFP entry?
<LetoThe2nd>
jonmason: yup
<jonmason>
cool, just trying to provide options
<jonmason>
submitting shortly
nucatus has quit [Remote host closed the connection]
<LetoThe2nd>
jonmason: cool, just let me know how I can help
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
mohamed-dhiamtir has joined #yocto
derRichard has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
<jonmason>
LetoThe2nd: is there a way to do CFP proposals for someone else? I wanted to sign up rburton for a few things
<LetoThe2nd>
jonmason: not directly i think, but i think its fair game to do a /s/jonmason/rburton/g on all proposals I gte ;-)
<jonmason>
That woi
<jonmason>
Err .. that works
seninha has quit [Ping timeout: 268 seconds]
* LetoThe2nd
is out then, gn
mvlad has quit [Remote host closed the connection]
brian82 has joined #yocto
manuel_ has quit [Ping timeout: 264 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
seninha has joined #yocto
florian_kc has joined #yocto
<khem>
rburton: perhaps wait till after release
<khem>
and we have some invasive changes
<khem>
so far clang 15.x is quiet and some smaller minor version bumps are expected which might be good for both master and langdale
<khem>
once 16x starts nearing it might be one reason to branch