prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
enok has quit [Ping timeout: 244 seconds]
mbulut_ has quit [Remote host closed the connection]
mbulut_ has joined #yocto
florian has joined #yocto
Guest53 has joined #yocto
<Guest53>
Can anyone tell me what this error is and how can I eleminate it "Problem: package wireless-regdb-2024.01.23-r0.noarch from oe-repo conflicts with wireless-regdb-static provided by wireless-regdb-static-2024.01.23-r0.noarch from oe-repo"
<mcfrisk_>
Guest53: git history says "wireless-regdb-static should be used with kernel >= 4.15. wireless-regdb can be used with older kernels". so don't install both to image, just the static one
<Guest53>
mcfrisk_ thank you very much for your reply. I have already done that. It installs me nothing in my rootfs/squashfs/etc/
<mcfrisk_>
Guest53: not even in /lib ? that's the target install path in the recipe.
<Guest53>
mcfrisk_ npe. I have cleaned and redone it
<mcfrisk_>
Guest53: pure poky wireless-regdb-static contains /usr/lib/firmware/regulatory.db and /usr/lib/firmware/regulatory.db.p7s so something in your build config breaks it, e.g. layers and bbappends. check bitbake -e output
<Guest53>
mcfrisk_ in my kernel recipe I am copying these two files cp -f ${WORKDIR}/firmware/regulatory.db ${WORKDIR}/firmware/regulatory.db.p7s ${WORKDIR}/git/firmware/. You mean that could be problem?
<mcfrisk_>
Guest53: yes but the error message would be about kernel and wireless-regdb packages having conflicting files
<Guest53>
mcfrisk_ my problem is that I find wireless-regdb/2024.01.23/deploy-rpms/noarch/ however not under /rootfs/
<mcfrisk_>
Guest53: wireless-regdb recipe builds wireless-regdb-static binary package which needs to be installed to the rootfs defined by image recipe.
<Guest53>
mcfrisk_ let me have a look into my image recipe
enok has joined #yocto
starblue1 has quit [Ping timeout: 265 seconds]
enok has quit [Client Quit]
enok71 has joined #yocto
starblue1 has joined #yocto
enok71 is now known as enok
Kubu_work has quit [Quit: Leaving.]
mbulut_ has quit [Remote host closed the connection]
mbulut_ has joined #yocto
ablu has quit [Ping timeout: 265 seconds]
ablu has joined #yocto
enok has quit [Quit: enok]
<Guest53>
mcfrisk_ could you please suggest me how should it be seen in image recipe. From my image recipe I am unable to comprehend how other packages lands in rootfs. Could you suggest me any documentation if you don't have me litte example how to implement it. I'll appreciate your assistance
kanavin_ has quit [Remote host closed the connection]
<Guest53>
mcfrisk_ thank you very much. It is very informative document.
<Guest53>
As far as I have understood if package resides in IMAGE_INSTALL: or PACKAGE_CLASSES: it would automatically be copied to rootfs forlder. Is it correct? if yes I have already added this package, however it didn't get copied to rootfs
<mcfrisk_>
Guest53: make sure any changes to bitbake recipes or config are actually effective by checking "bitbake -e" output for the recipe or image
<mcfrisk_>
Guest53: image rootfs only gets the full binary package dependency tree based on IMAGE_INSTALL variable. This could include packagegroups. Note that recipe is the source package name, not binary. Recipe name could be same as binary package name, but also may not, and a recipe can build multiple binary packages.
<Guest53>
mcfrisk_ thank you for your detailed explaination. I have added wireless-regdb-static in a packagegroup which then be built with my image. I could see wireless-regdb under /tmp/work folder, indicating it got built, however not under rootfs. do you suggest there could be other factors which hinders wireless-regdb to be added under rootfs
<Guest53>
mcfrisk_ I see only one entry for wireless-regbd in bitbake -e # $RECIPE_MAINTAINER:pn-wireless-regdb /sources/poky/meta/conf/distro/include/maintainers.inc:866 # "Unassigned <unassigned@yoctoproject.org>" RECIPE_MAINTAINER:pn-wireless-regdb="Unassigned <unassigned@yoctoproject.org>"
<mcfrisk_>
Guest53: if wireless-regdb-static is directly or indirectly via dependencies in IMAGE_INSTALL variable of the image recipe, then it will be installed to the image rootfs. Image classes and recipes can modify the image in various ways to even remove certain paths etc. All depends in your setup.
<mcfrisk_>
Guest53: then wireless-regdb-static is not getting installed to your image. you need to debug and fix that but all details depend on your setup which we can't see
<Guest53>
mcfrisk_ thank you very much for your insightful input. I'll have a look what means do I have to debug it and figure it out why is it not being installed
rfuentess has quit [Ping timeout: 265 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
Kubu_work has joined #yocto
rfuentess has joined #yocto
zpfvo has joined #yocto
Saur_Home30 has joined #yocto
Saur_Home2 has quit [Ping timeout: 256 seconds]
Saur_Home68 has joined #yocto
Saur_Home30 has quit [Ping timeout: 256 seconds]
RobertBerger has quit [Quit: Leaving]
xmn has joined #yocto
florian_kc has joined #yocto
tepperson has joined #yocto
ablu has quit [Ping timeout: 272 seconds]
ablu has joined #yocto
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
ablu has quit [Ping timeout: 265 seconds]
ablu has joined #yocto
rob_w has quit [Remote host closed the connection]
Guest53 has quit [Quit: Client closed]
ablu has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<tepperson>
I'm trying to build a system for a nios2 processor and am getting stuck on gcc-runtime. Here is the libstdc++-v3 config.log https://pastebin.com/Y1eikFM6
ablu has joined #yocto
<RP>
tepperson: it seems odd it can't find stdio.h
ablu has quit [Ping timeout: 252 seconds]
tepperson has quit [Ping timeout: 256 seconds]
ablu has joined #yocto
<landgraf>
RP: same error happened to me when I tried to build ada support in gcc. I tracked it down to the patch in yocto's gcc and gave up...
<landgraf>
the patch does some (reasonable) thing to build cross iirc.
farmadupe has joined #yocto
* farmadupe
waves
<farmadupe>
I have what I think is a fairly beginnerish question, I'm following the "yocto project quickstart" and I just want to understand I'm getting the right end of the stick
<RP>
landgraf: It would be nice to revisit the bootstrap process and see if we can align more closely with gcc. I remember trying ada myself and not finding a way to make it work easily
<RP>
farmadupe: feel free to ask!
<farmadupe>
It seems that when running `bitbake-layers create-layer meta-mylayer` to create a new layer, this creates the layer directly inside the poky git repo.
<landgraf>
farmadupe have you tried ../meta-mylayer for example ? :)
<farmadupe>
Is this the intended way of working, that if I would use the poky distribution, my custom layers are overlaid directly on top?
<landgraf>
iirc it should work
<farmadupe>
Oh, I'm just following the tutorial as written, I'm at a stage where I have to assume that what I'm told is the "correct" way
<RP>
farmadupe: creating it inside the poky repo isn't ideal, you'd put layers in their own git repo in general
<landgraf>
farmadupe: poky is reference distro and not supposed to be used in production. you will have to create your own distro (and layers structure) anyway
<RP>
farmadupe: I suspect the guide is just trying not to confuse things with more complex paths
<landgraf>
+1
<farmadupe>
ah ok, that's fine with me :)
goliath has quit [Quit: SIGSEGV]
<farmadupe>
one other beginnering question. I'm inheriting an existing Yocto project form a previous developer who's left jsut as we're transitioning from V1 to V2 of our product. So I'm here to update a bunch of deps and integrate some new hardware. The target is actually a fairly traditional x86 device, (fairly recent intel Atom, 8Gb RAM etc etc). I'm examining the existing codebase and system requirements, and
<farmadupe>
I'm trying to work out exactly why Yocto was chosen (unfortunately there's not much written documentation)
<farmadupe>
Am I right in assuming that this is possibly a bit of a smell? If there's no clear and obvious reason why a project should be using Yocto, then cheaper and easier alternatives could be considered?
<farmadupe>
I'm fairly sure that we could run our application on top of stock Debian (give or take some environmental isolation with docker or appimge or whatever)
<RP>
farmadupe: YP/OE have pros and cons like any system. Some of the pros are being reproducible, ability to maintain customisation, having complete control of all the components, able to generate license manifests and so on. Whether you need any of those things isn't for use to know/say
<farmadupe>
and I'm assuming that in any greenfield situation, you'd always go down that (or any similar route) rather than assembling an entire linux system from base parts?
<RP>
Debian has different pros/cons
<RP>
farmadupe: the answer would also depend on your background. I could assemble a YP derived system easier than debian...
zpfvo has quit [Ping timeout: 265 seconds]
* RP
isn't sure how he feels about the system he's spent years working on being described as having a smell :/
zpfvo has joined #yocto
<farmadupe>
Yeah indeed, I guess I'd call myself an experienced enough applications developer, so all of a sudden I'm faced with learning a lot of "operating system guts", whether Debian or Yocto
<rburton>
farmadupe: "just use debian" has trouble scaling to commercial products. how do you do license validation, GPL compliance, updates. do you run or your feeds (and thus rebuild all of debian) or piggyback on debian? etc etc.
<farmadupe>
whoops! I guess I mean smell in the nature of "did the previous developer choose Yocto because they wanted another line on their CV, rather than to serve the product"
<rburton>
remember that yocto is designed to build "embedded" products from, whereas debian is a general purpose deskop/server distro. yocto isn't a niche choice if you're making a product like that.
<RP>
farmadupe: one advantage is that it can build for different hardware profiles/architectures/configurations and customise to both easily and maintainably. We don't know what your product is or what your constraints are though
Saur_Home62 has joined #yocto
<RP>
YP's main downside is probably complexity and build time as it isn't pre compiled
zpfvo has quit [Ping timeout: 246 seconds]
tepperson has joined #yocto
<farmadupe>
yeah indeed. I wish I understood my own constraints well enough at this stage!
Saur_Home68 has quit [Ping timeout: 256 seconds]
<farmadupe>
hmm, perhaps one further yocto question, our product is expected to be connected to the internet possibly in a fairly unrestricted way. Whatever the real attack surface for security vulnerabilities might be, I'm expecting us to have to continuously update the base system.
<farmadupe>
In Yocto world, I'm assuming the developer generally has to do this by hand, and will have to take on the testing and validation workload. Are there any "shortcuts" to this process?
<farmadupe>
e.g "do your best to mirror Poky if youre distro hasn't diverged too much" or "don't use a lot of libs" or "don't have unrestricted network access"?
<RP>
farmadupe: there is a decent sized testsuite we run against the core and that can be used to test the system you're maintaining too
<farmadupe>
hmm, does the testsuite just test for successful compilation or is it able to exercise functionality?
<RP>
we run the test suites from the software we build too (ptests)
Saur_Home70 has joined #yocto
<farmadupe>
just to test my understanding, I guess those tests are building and running the example poky-based images from the Poky repo? Thus the further any yocto-built system diverges, the less meaningful they become?
<RP>
farmadupe: for most things except the ptests, correct
<RP>
the ptests are installed into minimal images and tested in isolation so we know the dependencies are correct
<RP>
(e.g. core-image-ptest-bash or core-image-ptest-coreutils)
<RP>
a lot depends on the kind of divergence too
<RP>
adding things to the image probably won't affect the openssh server on the most part. Your own custom init system would.
yudjinn has quit [Ping timeout: 272 seconds]
Saur_Home62 has quit [Ping timeout: 256 seconds]
yudjinn has joined #yocto
rob_w has joined #yocto
<rburton>
farmadupe: and you can run the tests yourself trivially
azzentys has joined #yocto
<rburton>
"bitbake core-image-ptest -c testimage" assuming your platform is runnable in a qemu
goliath has joined #yocto
azzentys has quit [Remote host closed the connection]
<farmadupe>
oh, a similar basic-environment-understanding question: In the initial tutorial you clone the Poky git repository, and start using the OE build environment that was vendored into the repo
<farmadupe>
Is it {required, preferable, ill-advised} to use the vendored OE build environment from Poky for further work, if my application is going to be build on top of Poky?
<rburton>
what specifically do you mean by 'vendored oe build environemnt'
<farmadupe>
is Poky coupled to the vendored OE build chain, or is it only there for convenience
<farmadupe>
the tuto asks you to run " git clone git://git.yoctoproject.org/poky ; cd poky; source oe-init-build-env ". So my understanding is that the Poky reference distro supplies its own build tooling
<farmadupe>
(as in, `source oe-init-build-env` injects bitbake into PATH). I'm assuming that there are many Yocto projects that do not use poky and therefore do not clone poky simply to obtain a yocto build environment
<rburton>
poky is basically just oe-core + bitbake + other bits glued together into a monorepo. so if you grab oe-core + bitbake yourself, you'll still do oe-init-build-env but configure it via templates to build your distro instead of poky
<rburton>
there no 'poky-specific' build tooling
<farmadupe>
ahhh right, so the poky repo on github is there mostly for the benefit of firsttimers like me?
pidge has quit [Ping timeout: 248 seconds]
rfuentess has quit [Remote host closed the connection]
<farmadupe>
(or for anyone else who saw no need to separate out the tooling from the reference system?)
<rburton>
its also a single repo that is the basis of the QA infrastucture
Kubu_work has quit [Quit: Leaving.]
Kubu_work has joined #yocto
Kubu_work has quit [Client Quit]
florian_kc has quit [Ping timeout: 265 seconds]
ederibaucourt has quit [Ping timeout: 255 seconds]
azzentys has joined #yocto
zpfvo has quit [Remote host closed the connection]
pidge has joined #yocto
leon-anavi has quit [Quit: Leaving]
tepperson has quit [Quit: Client closed]
ederibaucourt has joined #yocto
deribaucourt has joined #yocto
ederibaucourt has quit [Ping timeout: 265 seconds]
deribaucourt has quit [Quit: ZNC 1.8.2 - https://znc.in]
<tepperson>
on my nios2 target, I've made a bit of progress on gcc-runtime, adding "-I${WORKDIR}/recipe-sysroot/usr/include" to TARGET_CFLAGS and TARGET_CXXFLAGS, but am now running into an issue where "include_next <stdlib.h>" results in stdlib.h not found
<marex>
yikes
<marex>
that's nios2 fast that was recently removed from qemu ?
<khem>
tepperson:marex I have a hunch that it would be better to use something like kirkstone for the nios2 thing, if its being removed from upstream tools etc. things will fall apart with master
<marex>
khem: I have a hunch it would be better to use something like picorv32 or whatever is popular right now instead of altera proprietary core with decaying support in every concievable toolchain
<amelius_>
Hey, is there quick way to exclude a recipe form the generated SBOM?
<khem>
marex:yeah any micro based on riscv is better these days :)
<khem>
amelius_: maybe inherit nospdx ?
<khem>
in the concerned recipe
<marex>
khem: anything which is somewhat "standardized" is always better in the long run
<amelius_>
khem: ah i see, this is not in 5.0 thanks for the hint
<khem>
marex:yes, and opensource tooling which is community maintained goes long way too
goliath has quit [Quit: SIGSEGV]
<khem>
amelius_: yeah I think there is some interest in backporting this to scarthgap but dont know what all it needs to pull along to work properly
pidge_ has joined #yocto
pidge has quit [Ping timeout: 244 seconds]
enok has quit [Ping timeout: 248 seconds]
BrianL has joined #yocto
<BrianL>
Is there an easy way to specify the partition labels that get defined for image creation? I've not had any luck specifically with the boot partition label, if memory serves. I'm coming back to this problem after a break in looking at it ...
<marex>
khem: yep yep and yep
<marex>
khem: how can we be any more in agreement, any ideas ? :)
xmn has quit [Quit: ZZZzzz…]
Kubu_work has quit [Quit: Leaving.]
ablu has quit [Ping timeout: 265 seconds]
ablu has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
azzentys has quit [Remote host closed the connection]