invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
rob_w has joined #yocto
rfuentess has joined #yocto
ptsneves has joined #yocto
invalidopcode has quit [Quit: Ping timeout (120 seconds)]
invalidopcode has joined #yocto
apteryx has quit [Ping timeout: 246 seconds]
apteryx has joined #yocto
gho has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
davidinux has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
mvlad has joined #yocto
zpfvo has joined #yocto
olani- has quit [Ping timeout: 255 seconds]
olani- has joined #yocto
manuel1985 has joined #yocto
thomasd13 has joined #yocto
frieder has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
Guest6647 has joined #yocto
zpfvo has joined #yocto
<RP>
marex: I think it probably does need work but yes, it should be possible to automate
d-s-e has joined #yocto
florian_kc has joined #yocto
AlexanderKrimm[m has joined #yocto
bps2 has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
florian__ has joined #yocto
<Guest6647>
Hi everyone,22.
<Guest6647>
I am currently trying to update our build to use Mesa 22.0.3 + amdgpu driver. From my understanding Mesa would require "radeonsi" as the GALLIUMDRIVERS_LLVM. But once adding llvm I am always running into following error but only for mesa-native:
<Guest6647>
| llvm-config found: NO need ['>= 11.0.0']
<Guest6647>
| Run-time dependency LLVM found: NO (tried cmake and config-tool)
<Guest6647>
| Looking for a fallback subproject for the dependency llvm (modules: bitwriter, engine, mcdisassembler, mcjit, core, executionengine, scalaropts, transformutils, instcombine, amdgpu, native, bitreader, ipo, native)
<Guest6647>
| Building fallback subproject with default_library=shared
<Guest6647>
|
<Guest6647>
| ../mesa-22.0.3/meson.build:1696:2: ERROR: Neither a subproject directory nor a llvm.wrap file was found.
<Guest6647>
Has anyone some experience with the LLVM-pipe for Mesa and had the same problem?
<RP>
rob_w: that is horrible and not cross compile friendly. I'd probably just patch it out
<rob_w>
thx
<RP>
rob_w: if you wanted something upstreamable, you'd put a cache check around it and then pass in the cache value
<rob_w>
sorry that is out of my payroll ( know-how missing')
<rburton>
rob_w: code hasn't been touched for almost a decade, sure you want to trust it?
<rburton>
but yeah, delete large chunks of that configure.in, it's really bad practise
<rob_w>
rburton: true ... but it was the best i found for the "task" to limit bandwith on ethernet to coontrol cpu loads
<rob_w>
i will reconsider !
bps2 has quit [Ping timeout: 272 seconds]
<rburton>
a quick google suggests that 'tc' from iproute can do the same, and is actively maintained
<rburton>
and doesn't involve dlopening libc
<rob_w>
yeah tc was next on my list
GNUmoon has joined #yocto
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
d-s-e has quit [Ping timeout: 246 seconds]
bps has joined #yocto
bps has joined #yocto
zpfvo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<landgraf>
RP: shouldn't be this new logo of the bug triage meeting https://ibb.co/XjVHNH8 ?
<RP>
landgraf: heh :). Did we ever think it would be easy though? :)
<landgraf>
RP: well. that usrmerge bug looked easy for me...
<landgraf>
and ended up in bisecting gcc in langdale :-/
<landgraf>
mother told me "if you have bug - check you downstream patches FIRST" :D
<landgraf>
*your
<RP>
landgraf: true, sometimes they are a bit of a rabbit hole. The recent bitbake.sock one, I thought I'd debugged and fixed yet it happened again at the weekend
prabhakarlad has joined #yocto
<RP>
landgraf: Turned out langdale wasn't patched and was breaking master builds thanks to memory resident bitbake
* landgraf
never thought memres bugs are easy :-/
<landgraf>
as well as UI ones
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<RP>
landgraf: it is the ones which take a couple of weeks of work and result in a one line change that frustrate me :)
<JaMa>
:)
bps has quit [Read error: Connection reset by peer]
<barath>
has anyone encountered a situation where one build server installs a bunch of packages to an image, but it's not reproducible on another? I suspect there's something that happened in the tmpdir, which is reused, which causes packages to be installed via recommends. if I explicitly block them from being installed via recommends via PACKAGE_EXCLUDE then they're not installed. but it would be nice to know what's going on
<barath>
an on a related notes, does someone remember how rootfs-dbg is created in an image's workdir?
<barath>
mhm, but I was looking specifically in poky. seems it's in rootfs.py
ptsneves1 has joined #yocto
<barath>
I'm trying to figure out why my rootfs is populated with a bunch of packages I didn't ask for and trying to trace the dependencies (or recommends) that lead to that
<ptsneves>
@barath have a look at the package manager output log in the log.do_rootfs
<sudip>
any idea how can I add an extra patch to gcc when using openembedded-core? all the patches are mentioned in "gcc-12.2.inc".
GNUmoon has quit [Remote host closed the connection]
Poppy has joined #yocto
ptsneves1 has quit [Ping timeout: 246 seconds]
<barath>
thanks ptsneves, it's from opkg so it just tells me that the packages are being installed, but not why. it seems it's being installed because something recommends it, but not sure what
<landgraf>
sudip: bbappend in your layer
<ptsneves>
sudip: just add a patch as you normally would with a bbappend. That the original recipe uses a .inc file is irrelevant to you
<Poppy>
Hi, on kirkstone branch I got "Failed to execute /init (error -13)" error during boot. I don't find any tips on internet about the issue. Sometimes I just need to rebuild core-image-minimal to get it works but it's a little bit boring :(
<ptsneves>
barath: if there are recommendations being installed i think they also show there.
<sudip>
landgraf: openembedded-core has 10 bb files for gcc adding that inc file. so then I will need 10 bbappends ?
Haxxa has quit [Remote host closed the connection]
Haxxa has joined #yocto
* sudip
is building for risc-v
<landgraf>
sudip: it depends. add it to the one you use (or to all of them with gcc_%.bbappend, not recommeneded)
GNUmoon has joined #yocto
<sudip>
hmmm..ok.. thanks landgraf
<landgraf>
sudip: as ptsneves emtioned inc is irrelevant to you
<barath>
so, it lists the packages it explicitly installed, both the regular packages and the complementary packages. the packages that I'm confused about are installed automatically by opkg, theyre not listed in the output from yocto, only directly in opkg's output which says theyre being installed (but not why)
<sudip>
thanks landgraf ptsneves
prabhakarlad has quit [Quit: Client closed]
<rburton>
barath: then its a package dependency. if you're brave try pointing https://gitlab.com/rossburton/pkgexp at the pkgdata and look there.
prabhakarlad has joined #yocto
<ptsneves>
@barath then dump the task dependency list and have a look at what comes from what. -g is the flag although i think there are new task explorer tools that can also help. This assuming you are talking about extra recipes and not only packages
<barath>
I'm talking about packages in this case
<barath>
thanks rburton, that looks awesome :) I wrote a script to get through all the ipk control files to figure out the dependencies manually, but that only gave me -dev packages... so maybe something is causing -dev packages to be installed I didnt ask for
Haxxa has quit [Read error: Connection reset by peer]
kscherer has joined #yocto
<barath>
IMAGE_FEATURE is empty
<barath>
which is the weird thing
<barath>
I think the tmp dir has some left-over state from a previous build. this is from a CI which reuses the tmp dir again and again... (bad). it would just be nice to know what state can cause this, when bitbake -e tells me there are no IMAGE_FEATURES related to this etc
<ptsneves>
@barath i do see why the tmp dir is a bad thing. Perhaps some contamination is occurring but of another type. As rburton mentioned it would be good to analyze the control files to see where things are coming from
<olani->
barath: If it is just -dev packages, check if you have any that accidentaly contains a shared object (.so* file). This happens when recipes builds unversioned shared libraries and don't set their packages variables correctly.
<olani->
barath: The dev packages should only have symlinks named .so
<ptsneves>
olani-: oh, through shlib detection?
<olani->
yes
zpfvo has quit [Ping timeout: 248 seconds]
<barath>
hm it might be related to dev packages, but I'm not sure how yet. I'm getting perl and python3-core for instance, and for perl the only relevant packages seem to be qtbase-dev which is actually not installed I think
<barath>
however recently someone added package with a name which ends in -dev, but which is not a dev package... recipe for disaster I guess
grma has joined #yocto
<ptsneves>
@barath: I do not think adding a recipe ending in -dev is problematic from the technical point of view, in the sense of the issues you are seeing, but i might be wrong.
<barath>
well, I remember it triggering that QA warning about solibs being included in dev packages. but I dont see how it can cause perl to be installed (on some machines only)
alessioigor has joined #yocto
Poppy has quit [Quit: Client closed]
zpfvo has joined #yocto
Guest6647 has quit [Quit: Client closed]
mardor has joined #yocto
<olani->
barath: If some package installs a perlscript with a perl shebang, perl might get auto-installed.
frieder has quit [Ping timeout: 252 seconds]
tomzy_0 has joined #yocto
<tomzy_0>
Hello
<olani->
Or rather, the package might get an auto-dependency on perl
<barath>
mhm
<barath>
I think the problem is actually this package we have which has a name which ends with -dev. inspecting it's ipk, I see see that it recommends qtbase-dev, which recommends perl-dev
<tomzy_0>
Let's say I have a build for x86 platform real hardware and also a similar one for Qemu x86 target. Will it be possible to just build one target using generic-x86 machine config file and use it both on real hardware and emulated target?
<olani->
barath: Try addingg the problematic packages to PACKAGE_EXCLUDE and see if you get errors.
gsalazar has joined #yocto
<barath>
yeah that solves it
<barath>
anyone remember where in poky recommends are added to ipk control files? I suspect that if a package name ends with -dev, it automatically adds some recommends
<kanavin>
RP: thanks, I roughly agree. I'm on holiday this week, so I'll upload your email into my brain and let the neurons process it in the background, hopefully with course correction as an outcome.
<RP>
kanavin: sorry it took as long to write this down. The trouble is my feelings are a bit "fuzzy" on it, I don't know exactly what we need to do, I just have a feel this isn't right and some vague ideas of what might work better
<RP>
kanavin: I think it is something it would be very worthwhile to get right though
<mardor>
Hi all, I have a few packages that pull in mesa-native and within my build actually use mesa+radeonsi+amdgpu. I am able to build the mesa package but for some reason mesa-native can not build, because meson it is not able to pick-up the llvm-config13.0.1 for mesa-native. But it is actually present under:
<mardor>
x86_64-linux/mesa-native/2_22.0.3-r0/recipe-sysroot-native/usr/bin. Has anyone an idea to fix that so that meson can pick it up?
<tomzy_0>
mardor: what provides `llvm-config13.0.1`? Is it in depends of mesa-native? Could you share the actual build error
<tomzy_0>
Can I use generic_x86 machine config file and use built image both on real hardware and for qemu? If yes, will there be any significant drawbacks from not using specific machine configs? (one for qemu and other for given piece of x86 platform)
<mardor>
tomzy_0: Sure, the actual build error is:
<mardor>
WARNING: Ignoring LLVM CMake dependency because dynamic was requested
<mardor>
| llvm-config found: NO need ['>= 11.0.0']
<mardor>
| Run-time dependency LLVM found: NO (tried cmake and config-tool)
<mardor>
| Looking for a fallback subproject for the dependency llvm (modules: bitwriter, engine, mcdisassembler, mcjit, core, executionengine, scalaropts, transformutils, instcombine, amdgpu, native, bitreader, ipo, native)
<mardor>
| Building fallback subproject with default_library=shared
<mardor>
|
<mardor>
| ../mesa-22.0.3/meson.build:1696:2: ERROR: Neither a subproject directory nor a llvm.wrap file was found.
<mardor>
|
<mardor>
| A full log can be found at /tmp/work/x86_64-linux/mesa-native/2_22.0.3-r0/build/meson-logs/meson-log.txt
<mardor>
| ERROR: meson failed
sakoman has joined #yocto
dmoseley has quit [Ping timeout: 268 seconds]
<mardor>
And mesa-native has a dependency to llvm-native
<tomzy_0>
mardor I would check the used meson.build file to verify how meson want to use llvm. `ERROR: Neither a subproject directory nor a llvm.wrap file was found.` - is `llvm.wrap` present?
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
<rburton>
thats just because it failed to find llvm-config
frieder has joined #yocto
<barath>
yes, I think so landgraf! Thanks :)
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
<mardor>
tomzy_0 I think you are not that far off: I just checked my meson.native file and it does not list llvm-config option at all.
nemik has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
zpfvo has joined #yocto
tomzy_0 has quit [Quit: Client closed]
mckoan is now known as mckoan|away
d-s-e has quit [Quit: Konversation terminated!]
d-s-e has joined #yocto
<rburton>
when I find who named the arguments to find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache) i'm going to have words via the medium of a stout stick
* rburton
look at RP
d-s-e has quit [Client Quit]
d-s-e has joined #yocto
d-s-e has quit [Client Quit]
d-s-e has joined #yocto
kris has joined #yocto
<kris>
Hello all - Is there a standard docker container that is recommended as a starting point for building on a non-tested OS, such as Ubuntu 22.04?
<RP>
rburton: hmm, looks like it was me :(
<qschulz>
kris: CROPS I believe should help
<qschulz>
kris: IIRC you can also use buildtools directly, have never done it so can't say how to do it though
<kris>
@rburton - Thanks - not using kas at the moment, but it's on my list :-)
jatedev has joined #yocto
<landgraf>
sakoman: Sorry for sending two patches for the same issue (musl+arm). I tried to explain the reason in the cover letter of the second one, it looks too invasive for stable branch for me
<barath>
for the curious, my issue earlier today was indeed caused by us creating a package with a name that ends in dev. that lead to a Recommends being added for that backage, which in turn caused a bunch of other -dev packages to be included, ultimately including perl and python
<RP>
barath: that sounds like something we should probably try and improve, might be worth a bug report
<barath>
of course, we shouldnt have packages with names that end in -dev. maybe there could be a QA check for packages that end in -dev-dev, which could catch this (as long as default -dev packages are built)
tomzy_0 has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
<barath>
👌
rob_w has quit [Remote host closed the connection]
<RP>
barath: I'd love a patch which added that check!
dmoseley has joined #yocto
Herrie has joined #yocto
demirok has joined #yocto
Herrie has quit [Remote host closed the connection]
DarkestFM has quit [Read error: Connection reset by peer]
<phako[m]>
er...
<phako[m]>
2023-01-16 15:35:49 - INFO - | /home/msk_jenkins/workspace/Yocto_Image_build/build-zeus/build/tmp/hosttools/ld: ./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of `parseopt_program_args'; gdbm_dump.o:(.data.rel.local+0x50): first defined here
Herrie has joined #yocto
<phako[m]>
anyone seen that (and please don't ask me why zeus... I just have to)
Jham has joined #yocto
florian has quit [Ping timeout: 260 seconds]
mabnhdev has joined #yocto
<mabnhdev>
I'm working with Kirkstone. Poky started using meson to build some packages. For my mips (octeon2-o32) and arm32 platforms, several packages fail with the error './git/meson.build:3:0: ERROR: Executables created by c compiler ... are not runnable.'. To get around this, I'm going back and grabbing the most recent recipes for these packages that
<mabnhdev>
don't use meson and putting them in my meta layer. Before I really commit to that strategy, I wanted to check with the board first about any better way to deal with this.
<mabnhdev>
Everything builds fine for my aarch64 and x86-64 platforms, so I suspect it's an architecture-related problem.
florian_kc has joined #yocto
<landgraf>
mabnhdev: I've sent patch to address this today
<mabnhdev>
Cool. I keep an eye open. Thanks!
<mabnhdev>
landgraf Can you give me a pointer to your submission so I can track it?
<mabnhdev>
landgraf I won't be able to try it until later today or tonight. I'll let you know by firth thing tomorrow morning.
<rburton>
mabnhdev: using pre-meson packages is not the fix, its an ugly workaround, and it should work. meson is probably the best build system for cross compiling.
<mabnhdev>
rburton Understood. I'd rather see it fixed too. My plan is to submit issues; I'm just looking for a way to keep moving forward with my work while it gets addressed properly.
thomasd13 has quit [Ping timeout: 256 seconds]
<gsalazar>
Hello, what would be the best approach to add a variable to the u-boot environment that is define during the yocto build time?
<mabnhdev>
A question related to my ugly workaround... If I have recipes for the same version of a package in two different meta layers, is there any way other than layer priority to force the parser to select the recipe in a specified meta layer?
<AlexanderKrimm[m>
i had the same/similar issue when compiling to zen3/amd-milan. The problem there was, that meson compiles some test executable and tries to execute it. This required qemu to be setup correctly with the correct cpu instruction set, which was not the case by default when using the amd-meta layer. `QEMU_EXTRAOPTIONS_zen3 += " -cpu EPYC-Milan-V1,check=false"` which fixed the meson problem for me. But looking at that patch it seems that
<AlexanderKrimm[m>
this is another problem that just shares the similar sympthoms
<AlexanderKrimm[m>
* i had the same/similar issue when compiling to zen3/amd-milan. The problem there was, that meson compiles some test executable and tries to execute it. This required qemu to be setup correctly with the correct cpu instruction set, which was not the case by default when using the amd-meta layer. I ended up using`QEMU_EXTRAOPTIONS_zen3 += " -cpu EPYC-Milan-V1,check=false"` which fixed the meson problem for me. But looking at that
<AlexanderKrimm[m>
patch it seems that this is another problem that just shares similar sympthoms
SatR has joined #yocto
frieder has quit [Remote host closed the connection]
<SatR>
on ubuntu 22.10 I got ModuleNotFoundError: No module named 'sqlite3'
leon-anavi has quit [Read error: Connection reset by peer]
<RP>
qschulz: it is a lake district pass, one of my favourites
<qschulz>
RP: wait, they say it's a stone
<qschulz>
"The name of the pass comes from a prominent stone, the Kirkstone, which stands a few yards from the A592 on the Patterdale side of the inn"
<RP>
qschulz: sure, but it is pronounced stun ;-)
<qschulz>
"The church-like Kirk Stone at right" I'm getting mad
<qschulz>
RP: I meant to say that maybe the Yocto release is not named after a pass but after a stone (whgatever the pronunciation is :) )
<RP>
qschulz: well, you have to ask what the other releases are named after? :)
* JaMa
likes RPs "travel blog across releases" on FB
<RP>
if kirkstone is challenging, the release after mickledore is going to be a nightmare
<rburton>
haha
<rburton>
i've already had people complaining and they're from manchester :)
<JaMa>
the last photo from 8th? is from the last release?
<mario-goulart>
kergoth survided krogoth, I guess
<RP>
JaMa: sadly that hill isn't in the lake district
<RP>
JaMa: that one was from a "secret" location in the cheviots where I was trail building for "reasons"
<JaMa>
ah, thanks
<JaMa>
so I was googling wrong pictures to compare :)
azcraft has joined #yocto
<RP>
JaMa: it is called "inner hill" apparently, so that won't help anyone locate it in the slightest as there are three I can see on the map in 15 miles alone
<RP>
JaMa: there were pictures from the release after mickedore last year btw, I did ride a mountain bike down it
alessioigor has quit [Quit: alessioigor]
prabhakarlad has quit [Quit: Client closed]
<JaMa>
I'm glad to see that you sometimes forget the 'l' in mickledore as well (probably my most common typo last year)
florian_kc has joined #yocto
seninha has quit [Quit: Leaving]
ChanServ has quit [shutting down]
florian_kc has quit [Ping timeout: 264 seconds]
ChanServ has joined #yocto
florian_kc has joined #yocto
kris has joined #yocto
<paulbarker>
moto-timo: I've opened a PR on the crops repo to deploy containers to ghcr.io. Looks like a couple of the build jobs have failed, they look like possible intermittent network or server issues
<paulbarker>
I can't see the permission or role controls as I'm not an admin on the crops org
<paulbarker>
It looks like it allowed the creation of a `yocto` container name for the first job that got to the deploy, then the rest were denied permission to push new tags to it
<moto-timo>
paulbarker: that is unfortunate, because we will _always_ have multiple tags
<paulbarker>
moto-timo: I hope it's a one time permissions fix to allow the jobs to push more tags
mabnhdev has quit [Quit: Client closed]
<paulbarker>
I should have tested this in a repository under a github org, instead of a personal repository, silly me to assume they'd work the same
manuel1985 has joined #yocto
<paulbarker>
moto-timo: If you've got 15 min at any point this week I'm happy to hop on a call to look at this. May be easier if you screen share what you can see with admin permissions and we both look at it
<paulbarker>
Since I can't even see the settings page to guess what may be wrong
<moto-timo>
paulbarker: I'm trying to read the docs now, but I didn't see anything obvious in the settings.
<paulbarker>
moto-timo: If you grant me admin temporarily I can have a look, or we can look at it via a screen share
<moto-timo>
paulbarker: yep, we have functionality (only the fedora-35 job failed... mirror issue)
<moto-timo>
paulbarker: I linked the PR to the poky-container ghcr request/issue
<paulbarker>
moto-timo: However, I think it's now private. I can't pull an image without being logged in and https://github.com/orgs/crops/packages is empty if I open it in an incognito session
<paulbarker>
I've gone ahead and made it public
<paulbarker>
Let's hope it can still be pushed to next time
<moto-timo>
paulbarker: should be ok now... but we need to remember to do the same dance for any other repo/packages...
<paulbarker>
moto-timo: Yes, it's definitely a bit of a dance
<moto-timo>
paulbarker: I was able to `docker pull ghcr.io/crops/yocto:ubuntu-22.04-base`
<paulbarker>
moto-timo: Same here, looks good
<paulbarker>
I'll look at poky-container next though won't have chance today
<moto-timo>
paulbarker: thank you for figuring out the solution, it was easier than I thought, but not trivial
marex has quit [*.net *.split]
jamestperk has quit [*.net *.split]
polprog has quit [*.net *.split]
derRichard has quit [*.net *.split]
vvn has quit [*.net *.split]
marex has joined #yocto
polprog has joined #yocto
derRichard has joined #yocto
vvn has joined #yocto
jamestperk has joined #yocto
sakoman has quit [Quit: Leaving.]
<paulbarker>
moto-timo: I'll be glad to not have to depend on Docker Hub for these containers in the future :)
Jham9 has joined #yocto
robbawebba has joined #yocto
Minvera has joined #yocto
seanjohnstontips has joined #yocto
Jham9 has quit [Quit: Leaving]
mvlad has quit [Remote host closed the connection]
Bardon_ has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
vladest has joined #yocto
gsalazar has quit [Ping timeout: 252 seconds]
vladest has quit [Read error: Connection reset by peer]
vladest1 has joined #yocto
gsalazar has joined #yocto
vladest1 is now known as vladest
mouser is now known as Ch^W
seninha has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
olani- has quit [Ping timeout: 260 seconds]
Minvera has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
prabhakarlad has joined #yocto
<apteryx>
hi! where can I find the code used to generate RPM packages in Yocto?
<yocton>
Look for package_rpm.bbclass maybe?
<apteryx>
thanks, that seems to be it!
pidge has quit [Remote host closed the connection]