tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
enok has quit [Read error: Connection reset by peer]
Daanct12 has quit [Ping timeout: 252 seconds]
alessio has joined #yocto
goliath has joined #yocto
Daanct12 has joined #yocto
asgj-gomspace has joined #yocto
rob_w has joined #yocto
eduter has joined #yocto
enok has joined #yocto
asgj-gomspace has quit [Quit: Client closed]
treje has quit [Quit: Leaving]
eduter has quit [Quit: Client closed]
zeemate has joined #yocto
eduter has joined #yocto
eduter has quit [Ping timeout: 240 seconds]
rfuentess has joined #yocto
eduter has joined #yocto
ericksonu has quit [Ping timeout: 276 seconds]
mckoan|away is now known as mckoan
enok has quit [Ping timeout: 248 seconds]
jclsn has quit [Quit: WeeChat 4.5.1]
<eduter>
Hi everyone. I am updating my Yocto build system from kirkstone to scarthgap.
<eduter>
I observed that some of the repositories I am using do not come with tags and others do. For example:
<eduter>
"meta-security" comes with branch "scarthgap" and todays last revision is bc865c5276c2ab4031229916e8d7c20148dfbac3.
<eduter>
"meta-arm" comes with branch "scarthgap" and todays last revision is 3cadb81ffaa9f03b92e302843cb22a9cd41df34b. HOWEVER, there is a possibility to reference tag yocto-5.0.15.0.1 (referencing an older commit)
<eduter>
What would be best practice here? to reference to the latest commit hash on scarthgap branch or, if tags are available, reference to them in my Yocto build system manifest file?
<eduter>
maybe a "newbie" question... but I am trying to learn/understand good practice/habits, therefore, I want to learn basic and non-basic stuff from this community, please.
davidinux has quit [Quit: WeeChat 4.3.1]
<eduter>
thanks!
<mckoan>
eduter: Depends(TM) :-D
<mckoan>
eduter: if you need reproducibility you should use the latest one (if is possible) and then stay on that
<mckoan>
eduter: if you can affrod it, the best option would be to keep everything updated to the last commit in a LTS branch
wojci has joined #yocto
<eduter>
mckoan I need reproducibility, I am afraid :D I am just wondering why not all the "repositories" containing Yocto layers are using tags xD
<mckoan>
eduter: because depends
<mckoan>
eduter: a tag is not mandatory, therefore you usually use a SHA
<eduter>
mckoan just wondering why in my manifest file for some repos I specified the commit-hash for revision, and for others I can specify the tag
<mckoan>
eduter: as I stated
<eduter>
mckoan thanks for the answer! then maybe a dummy question... would not be cleaner working with tags?
<mckoan>
eduter: now you already know the answer :-D
<eduter>
mckoan yes! thanks mckoan got my answer! I need reproducibility so I will stick to specific SHAs or TAGs if they available.
berton_ has joined #yocto
<LetoThe2nd>
eduter: while it won't happen on official repos, tags can be moved. hence, the canonical path is using SHA revisions.
berton_ has left #yocto [#yocto]
<eduter>
LetoThe2nd thanks! I guess this was more a git version control question. . Thanks for clarifying my confusion. I guess sticking to SHAs is the safest, even though tags will never be moved on official repositories. Ok!
rfuentess has quit [Remote host closed the connection]
ello_ has joined #yocto
eduter has quit [Quit: Client closed]
eduter has joined #yocto
berton has joined #yocto
enok has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
enok has quit [Client Quit]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
<RP>
eduter: the branch names are generally the way we show compatibility between different branch/layers. Stable fixes would tend to go onto stable branches and we tag the configurations we test/release. It is up to individual layers how closely they follow that. Generally the latest commits on stable branches should be ok
<eduter>
RP thanks for the answer. I guess I was a bit curious to ask about why some repositories have tags (e.g. meta-arm) while others did not (e.g. meta-security). Nevertheless, it is good to know that generally the latest commits on stable branches (for example "scarthgap") should be ok :-)
enok has quit [Ping timeout: 244 seconds]
enok has joined #yocto
davidinux has quit [Ping timeout: 244 seconds]
eduter has quit [Quit: Client closed]
eduter has joined #yocto
enok has quit [Ping timeout: 260 seconds]
enok has joined #yocto
<LetoThe2nd>
eduter: technically that is correct, yes. but in the past, I have witnessed build breakage when following the head of branches, and it make it hard to reproduce builds. my personal take is to have two sets: a "stable" one, using SHAs that you verified, and a branch-next which follows the current branch HEAD.
<mcfrisk>
but when running into issues, it's very annoying to debug them for hours only to find out that latest branch head already has the fixes
<eduter>
LetoThe2nd I will keep in mind start using this strategy having a second repo "branch-next" which follows the latest and greatest. Probably no happening soon for me, but good to know about this practice. I will try to enforce it when I have the time.
<mcfrisk>
I've rarely run into issues on branch commits. it's anyway up to me to make the distro, configuration, machine, use cases etc work.
<LetoThe2nd>
mcfrisk: that tells me you're not involved in meta-tegra ;-)
<eduter>
mcfrisk I guess if I experience issues after I manage to upgrade to scarthgap and successfully build and produce an OS image, I can start thinking off this "branch-next" which produces an OS image using the latest and greatest which I could use to attempt to reproduce the same bug/issue observed.
<eduter>
mcfrisk mmmm not familiar with that repo or that layer to be honest, you are correct :D
vthor_ has joined #yocto
<JaMa>
Is Tim the only person who can help with some admin changes on layerindex?
vThor has quit [Ping timeout: 260 seconds]
<JaMa>
I have admin rights to publish new layers, but cannot delete wrongly created one and I'm not sure how to add a new mapping (e.g. some 6.8 branch from meta-qt6 as compatible with scarthgap release or 'dev' branch which is currently used only for master release, but the layer.conf in dev and 6.8 has: LAYERSERIES_COMPAT_qt6-layer = "kirkstone langdale mickledore nanbield scarthgap styhead walnascar")
<mcfrisk>
LetoThe2nd: there are good and bad layers of course. vendor layers can be, ahem... but not following open source layer branch commits results in missed fixes and security updates unless the layers do releases. not many do. using kas/repo/git submodules to manage layers is a must and each build can be unique and break absolutely everything
<RP>
JaMa: rburton may be able to help
<JaMa>
RP: thanks, rburton will send e-mail with details shortly
<RP>
JaMa: I have some access but I'm probably not sure what to do...
<JaMa>
I've finally pushed meta-webosose branches which use release codenames (so that we don't need to use "actual branch master" for kirkstone and will get scarthgap release as well "automatically") so now the biggest offender is meta-qt6 I think and I don't know how to fix that as well
<JaMa>
RP: I've sent e-mail to oe-core, Tim, Samuli and Ross, hopefully one of them will be able to help (or show me how to fix it myself)
<berton>
Hello! The other day I asked about how to create a small ext4 filesystem, and I'm still not sure what is the correct way to do it. I want to be able to create a 20M ext4 rootfs using 1k block size, but the directory_size function that sets the ROOTFS_SIZE is using 4k block size and the final size of the rootfs is always greater than 20M.
<berton>
What I did was add this in image.bbclass:
<berton>
and add `IMAGE_ROOTFS_EXACT_SIZE = "1"` on my image to use the exact size I added in IMAGE_ROOTFS_SIZE and not the one calculated by ROOTFS_SIZE.
<berton>
Do you have any ideas on how to create an image with the exacted size that was set in IMAGE_ROOTFS_SIZE?
eduter has quit [Quit: Client closed]
eduter has joined #yocto
<RP>
berton: I suspect the code in this area could do with some improvement around handling the different block sizes. The trouble is different filesystems can do different things with them
<berton>
RP: But how do I know the block size? For ext4 the block size may be different if I don't set the `-b <size>` option. I don't know how to handle all cases.
bielpa_ has joined #yocto
pbiel has quit [Read error: Connection reset by peer]
<RP>
berton: that is why this hasn't been fixed I suspect :/
bielpa__ has joined #yocto
bielpa_ has quit [Remote host closed the connection]
<rburton>
berton: fwiw genimage gives you direct control over the final filesystem so maybe try that. there's an integration class in meta-ptx.
<berton>
RP: yes. And does it make sense to add a way to set the ROOTFS_SIZE using IMAGE_ROOTFS_SIZE?
<landgraf>
genimage++ :)
enok has quit [Ping timeout: 268 seconds]
<berton>
rburton: Thanks for sharing. I'll check the bbclass.
savolla has joined #yocto
pidge_ has joined #yocto
pidge has quit [Ping timeout: 260 seconds]
Ad0 has quit [Ping timeout: 252 seconds]
Ad0 has joined #yocto
<kanavin>
eduter, some layers have tags and some do not, because they all have different maintainers and owners and practices. You only need to ensure that when you give your yocto build to someone else, they will be building from exact same layer revisions as you are, otherwise it's madness trying to replicate what others have.
<kanavin>
unfortunately we do not yet have an official way to specify and replicate yocto builds, but kas/repo/git submodules can help
<eduter>
kanavin Ok kanavin! Reproducibility is important for me so I will stick to a specific layers revision. What is kas/repo/git submodule?
rfuentess has joined #yocto
<kanavin>
these are all tools that can help with setting up a set of layer repositories in a reproducible way (e.g. the revisions are fixed in a config file)
<eduter>
kanavin ok thanks!
<kanavin>
eduter, the best practice is to have to configs: one that pins layer revisions, and another that builds from latest commits in matching branches
<kanavin>
the first one is stable and tested (but periodically pushed forwards), the second one can fail in various ways and serves as early notice of issues that need to be addressed
<eduter>
kanavin yes, I get your point know. I am using a manifest xml file for that :-)
<kanavin>
eduter, I'd even suggest you set up a build from tips of master branches
<kanavin>
so that you do not have to do big bang transitions from one lts to the next in the future, but rather approach the next lts in manageable steps via building master
<eduter>
kanavin I will consider having as a strategy a build system pulling the latest and greatest as other colleagues in this community suggested me, yes :-)
<eduter>
kanavin also I understood that it could help to have a yocto build system NEXT pointing to master latest revision, to verify if errors/bugs on my other Yocto build system (based on scarthgap) may have already been fixed. Thanks for the tips on good practices!!!
<kanavin>
eduter, not only that. if you have master builds, then when the next lts is released in one year, you get it 'for free', without having to do a mountain of transition work with unpredictable schedule of how long it takes
<Tyaku>
Did someone know a "tips" to test the watchdog during the kernel boot ? When the system is booted i run this: 'echo c > /proc/sysrq-trigger' (to provoke panic and freeze), but during bootup sequence IDK. My unique idea is to create a driver "to panic on boot" but..
<JaMa>
RP: is master already separated from walnascar or do you plan to push current master to walnascar a bit later?
<Tyaku>
.. There is probably better solution
<eduter>
kanavin I see your point now. I will try to ensure I get time and priority for adding this second NEXT build system.
<RP>
JaMa: separated
<RP>
JaMa: I may add something if needed to walnascar but they're now separated
enok has joined #yocto
davidinux has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
trialBanana has joined #yocto
enok71 is now known as enok
trialBanana is now known as kiwi
kiwi has left #yocto [#yocto]
ablu has quit [Ping timeout: 252 seconds]
savolla has quit [Quit: WeeChat 4.4.3]
ablu has joined #yocto
<landgraf>
What is the best practice of using sstate cache? I've added aarch64 build to the CI and rebuild takes more than one hour even if the only change is DISTRO_VERSION. Rebuild of x86 machines takes 10minutes which is ok. Should I use sstate dir per arch or something like that?
savolla has joined #yocto
<RP>
landgraf: it can all be combined, separating it won't help or change anthing
<RP>
landgraf: something else is wrong if it isn't being reused
<landgraf>
RP: It was written somewhere deep in my memory too, thank you. It's AWS codebuild + EFS storage as sstate cache, not sure that's causing this...
<landgraf>
time to add diffsigs here for debugging
<RP>
landgraf: I think that is your best option
rob_w has quit [Remote host closed the connection]
tgamblin has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
tgamblin has joined #yocto
duracrisis has joined #yocto
<JaMa>
RP: thanks
prabhakalad has quit [Ping timeout: 268 seconds]
prabhakalad has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
savolla has quit [Quit: WeeChat 4.4.3]
enok has quit [Quit: enok]
enok71 has joined #yocto
savolla has joined #yocto
enok71 is now known as enok
mihai has joined #yocto
cyxae has joined #yocto
miau_miau has joined #yocto
<miau_miau>
Hi all. Is it possible to override variable flags from local.conf (or similar), globally? I'm trying to set a custom data layout to be used in the rust wrappers, but I'm failing. I'm trying 'DATA_LAYOUT[riscv64gc] = "mylayout"' in local.conf, but it doesn't seem to take effect in the generated rust wrapper. Not sure if what I'm trying is even
<miau_miau>
possible
wojci has quit [Ping timeout: 252 seconds]
eduter has quit [Quit: Client closed]
eduter has joined #yocto
Xagen has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 has quit [Ping timeout: 252 seconds]
miau_miau has quit [Quit: Client closed]
miau_miau has joined #yocto
dgriego has quit [Quit: Bye]
<miau_miau>
Looking a bit further with bitbake -e, I see that my value change does take effect, but it is overwritten by rust-target-config.bbclass... would it be possible somehow to make my value the last one that takes effect?
<vmeson>
miau_miau: One way to allow you to do that would be to use the weaker "=?" operator but that isn't done at all for any rust target.
<rburton>
mcfrisk: do you have a public branch with your meta-arm edk patch in? line endings in edk means you can't share patches over mail...
<vmeson>
miau_miau: it seems that you are trying to define a new BSP variant, why not do that rather than override DATA_LAYOUT[riscv64gc] ?
<mckoan>
miau_miau: I would give a try to DATA_LAYOUT:forcevariable[riscv64gc] but not sure
goliath has quit [Quit: SIGSEGV]
<rburton>
you can't use overrides and flags at once
<vmeson>
miau_miau: never mind, that's an abandoned layer it seems.
<miau_miau>
I'm just trying to use a bit newer version of rust than what's available in the mixin layers (trying to add 1.82 to kirkstone and scarthgap in a local layer), but it also seems to come with data layout changes, which I was hoping to solve with a line or two (not only for risc, but for others also. risc was just one example). But I start to think
<miau_miau>
that I was too optimistic, and I might not get away without getting deeper
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.6.0]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
dgriego has joined #yocto
miau_miau has quit [Quit: Client closed]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
<eduter>
@miau_miau I am not sure if I understood correctly what want to achieve... but I spent 2 weeks attempting to add meta-rust to my Yocto build system "kirkstone", in order to ensure that the build system will use the 1.82 toolchain I had to set these two variables in my bblayers.conf (not saying that this is good a bad practice of the perfect
<eduter>
solution, but it worked for me to be able to move on):
<eduter>
# RUSTVERSION: Specifies the minimum acceptable Rust version (1.82.x), overriding the default in the meta layer (1.59%).
<eduter>
RUSTVERSION = "1.82%"
<eduter>
# RUST_VERSION: Specifies the exact Rust version to use (1.82.0), which is the latest available in the meta-rust layer.
<eduter>
RUST_VERSION = "1.82.0"
<eduter>
without overriding the value of these two, my yocto build system would have continue using Rust toolchain 1.59.0
<eduter>
if this is not the issue you are facing then sorry for the confusion
wooosaiiii has quit [Remote host closed the connection]
Guest92 has joined #yocto
wooosaiiii has joined #yocto
Guest92 has quit [Client Quit]
Guest92 has joined #yocto
<Guest92>
is there anyone who can tell me if there is working recipe of latest https://github.com/gorilla/websocket? I have created a recipe through devtool however end up getting error go: cannot find main module, but found .git/config in /yocto to create a module there, run: cd /.. && go mod init WARNING: exit code 1 from a shell command.
<vmeson>
guest92: that would explain why I hadn't heard of meta-go ! ;-)
<Guest92>
vmeson yes indeed, I don't think that it's been maintained anymore
zeemate has quit [Ping timeout: 252 seconds]
Guest92 has quit [Quit: Client closed]
Guest92 has joined #yocto
ederibaucourt has quit [Ping timeout: 248 seconds]
ederibaucourt has joined #yocto
enok has joined #yocto
eduter has quit [Quit: Client closed]
alessio has quit [Quit: alessio]
<vmeson>
Zepto Linux uses quantum AI computers to test all possible build options and multiverse configurations to see which one will make the build wavefunction collapse and drive the AI mad !
<arielmrmx>
it generated a bunch of new files, but no luck flashing either, they do not seem to correspond to the required files
florian_kc has joined #yocto
zeemate has joined #yocto
<arielmrmx>
i can successfully create either .wic or rockchip_gpt_img
<arielmrmx>
both in fact
savolla has joined #yocto
druppy has joined #yocto
<rburton>
kanavin: can you remember anything about esdk creation? specifically i just noticed that the deployed manifest files are empty, so testing doesn't work properly.
olani- has joined #yocto
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
druppy has quit [Ping timeout: 244 seconds]
bielpa__ has quit [Ping timeout: 248 seconds]
tgamblin has quit [Read error: Connection reset by peer]
druppy has joined #yocto
<RP>
JaMa: your patch to the autobuilder should be live
cyxae has quit [Quit: cyxae]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
enok has quit [Remote host closed the connection]
druppy has quit [Ping timeout: 252 seconds]
Kubu_work has quit [Quit: Leaving.]
savolla has quit [Quit: WeeChat 4.4.3]
<JaMa>
RP: thanks, will check that on friday when it runs, then Hieu will send update to switch ose from kirkstone to scarthgap
GillesM has joined #yocto
GillesM has quit [Client Quit]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]