<TRO[m]>
@halstead: wiki.yoctoproject.org ssl cert is outdated
brrm has joined #yocto
beneth has joined #yocto
prabhakar has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
amsobr has joined #yocto
florian has joined #yocto
<RP>
rburton: patches merged
zpfvo has quit [Ping timeout: 240 seconds]
mlaga97 has quit [Server closed connection]
mlaga97 has joined #yocto
<ykrons>
Hello all
<ykrons>
I'm trying to build an image based on Yocto 3.0 in a CROPS container in WSL and I get weird error. I know it is not official supported, but is there known issue with that setup ?
zpfvo has joined #yocto
amsobr has quit [Quit: Konversation terminated!]
amsobr has joined #yocto
paulg has quit [Ping timeout: 246 seconds]
yokto has joined #yocto
<yokto>
How is yocto going to keep up with the upcoming wave of RISC-V devices in the future in which all of those devices can have a completely different architecture due to the way RICS-V is designed?
<yokto>
Or rather, different design should I say.
<yokto>
Will it still be possible to have the same way of working with meta-layers (for example meta-raspberrypi has one layer, but suppose each rpi will be built much different)?
Thorn_ has joined #yocto
<landgraf>
yokto: support of few boards have been added to meta-clang already you can check this out
Thorn has quit [Ping timeout: 255 seconds]
<yokto>
landgraf those are supporting risc-v platforms, not full BSP's
kpo has joined #yocto
paulg has joined #yocto
<rburton>
yokto: machine-specific pieces sit in BSP layers, so the answer is "better than traditional distros"
<LetoThe2nd>
yokto: its not yoctos job to cater for all the variations that some hw vendor cranks out. if a vendor wants their stuff to be used, they better figure out how to make it accessible to users and developres. providing a proper yocto bsp might be one approach.
<LetoThe2nd>
yokto: and vice versa, if users and developers care about such, then they should approach the risc-v people and the hw vendors in that space to actively contribute and become member organizations.
<yokto>
LetoThe2nd Agreed, but on the other hand yocto provides its tool in order for easy creation of images for these boards so perhaps something in yocto is going to be changed to make RISC-V boards more easily managable (and yes this should indeed be done by the RISC-V hw vendors...)
<LetoThe2nd>
yokto: if you feel like this is the direction, then you are invited to contribute such, and as already said, encourage the risc-v people/vendors to join us.
<yokto>
RISC-V development is going fast but it's going to take a while to catch up anyways. Kinda suprising how three people at a university shaked the industry... I thought big companies like Huawei should have been able to come up with something like that... three people created RISC-V, one person created the linux kernel... amazing
<rburton>
yokto: i'm struggling to understand how the bsp layer and machine/tune design fails with riscv. can you explain?
<yokto>
rburton competitors of RISC-V provide standardized core architectures whereas RISC-V encourages non-standardized core architectures which hardware-wise is a good thing because they can optimize everything for their specific application. However, this latter (can) introduce fragmentation (future will tell).
xmn has quit [Read error: Connection reset by peer]
<rburton>
yokto: sure. this is terrible for riscv, but a bsp layer for a specific custom riscv core can set the right flags/tunes/etc for the buid.
<LetoThe2nd>
yokto: again, i am convinced that it boils down to "if you want to sell hw, then you make sure people can use it and provide proper software support". fragmentation or not, i don't care what they do underneath as long as they provide a proper software stack that makes their offer usable. if they don't, i will go with a competitor.
<kanavin_>
I can't for the life of me understand why people choose hardware vendors based on silicon spec sheet only
<LetoThe2nd>
yokto: yocto is a tool that they can use to archieve that. if they want to talk, we are here. but we're not going to do their work.
<kanavin_>
software is just as important, if not more, and no one cares when making those decisions
<kanavin_>
or maybe they simply have no idea how to judge the quality of the software support
<LetoThe2nd>
kanavin_: i can. sales people and corporate buyers just buying by price and spec sheet. but again, not our problem to solve.
AKN has joined #yocto
<kanavin_>
keeps consultants busy, but it's not exactly the kind of 'busy' I like
<LetoThe2nd>
i know, i know.
<yokto>
I see. Well, life is mostly about having a good curriculum vitae meaning software developers will contribute anyways to these kind of open source projects, but that's their decision. Thanks.
<yokto>
Now I have a better understanding of where yocto fits in this picture. Lets see what the future brings :)
<kanavin_>
open source community is not someone's unpaid contractor
<qschulz>
kanavin_: BOM cost can rarely be reduced, you can however spend years making the SW support better
<kanavin_>
people work on problems that either interest them because it's fun, or they are paid for it
<LetoThe2nd>
yokto: if you actually believe "life is mostly about having a good curriculum vitae meaning software developers will contribute anyways to these kind of open source projects" means that in order to have a nice CV you should do free work for a HW vendor, then it is something you should definitely reconsider.
<kanavin_>
my life is about building things that last, and contributing to the pool of public knowledge
<kanavin_>
if that requires a good CV, then I'll make it good, if not, I don't care about how CV looks like :)
<LetoThe2nd>
yokto: not only because for yourself, but its actually making life for everybody worse. people can't eat exposure and pay their bills with it. you are encouraged to have a look at the situation for graphics designers, writers, etc.
<yokto>
kanavin_ Human Resources cares though :)
* LetoThe2nd
sighs and returns to doom. literally.
<kanavin_>
yokto, yes, one needs to pass the 'HR buzzword filter' to get to the hiring manager. but that's not a 'life is about' thing
<yokto>
LetoThe2nd A.I. indeed destroyed graphics designers and writeres careers... right now it is helpful for software engineers I would say though
<yokto>
kanavin_ true
<qschulz>
yokto: greed is what destroyed their career :)
<qschulz>
(and not theirs to be clear)
<kanavin_>
yokto, except it didn't. people are waking up to the fact that AI, as of now isn't as good at writing as actual writers.
<kanavin_>
both in technical writing, and in fiction
<qschulz>
kanavin_: translation services are apparently now fixing the thing AI translated for them, so this industry too :)
<LetoThe2nd>
kanavin_: well, what AI gives you as technical writing is actually good fiction ;-)
<qschulz>
(dang can't write properly today, "for them" understand people replaced them with AI and they are contracting experienced translators to fix the thing AI came up with)
<qschulz>
(back to the lurking mode because i cannot speak :) )
<kanavin_>
the most it can do is a particularly bland, flavorless school essay kind of thing, one that doesn't cite sources, and so would be laughed out of the gate in any serious scientific setting
<qschulz>
kanavin_: incorrect, it does cite sources.... which do not exist :D
<LetoThe2nd>
qschulz: best kind of citation![1], [1]: LetoThe2nd, 2023-06-13
zeddii has quit [Ping timeout: 240 seconds]
<landgraf>
kanavin_: good thing about open source is that it helps to bypass HR filter...
<rburton>
_can_ help
zeddii has joined #yocto
AKN has quit [Ping timeout: 240 seconds]
<landgraf>
rburton: right. one of the key kernel maintainers I worked with has been rejected by HR with "not enough experience with Linux kernel"...
<yokto>
landgraf A.I. needs to replace HR immediately (like Amazon is doing)
<landgraf>
better not to discuss Amazon (AWS) HR topic here :D
<yokto>
Never really understood how HR works. Engineers work really hard to get an engineering degree and gain experience in the field, next thing you know they are assessed by people that studied a random study and suddenly came into HR blocking those engineers entering tech companies.... everyone seems fine with this
hays has quit [Ping timeout: 240 seconds]
<landgraf>
yokto: well. HR not always understands how software engineers work...
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<Ablu>
Can I somehow clean all -native packages? Things become weird with a system update and it looks like some inconsistency in -native packages...
AKN has joined #yocto
florian_kc has joined #yocto
<rburton>
delete tmp and then delete all *-native* files in your sstate if you just want to wipe them all to be sure
prabhakarlad has joined #yocto
<rburton>
Ablu: though if you just upgraded to an unsupported distro...
<rburton>
you might have just hit the gcc13 issue
<Ablu>
rburton: yeah, it most likely has something to do with gcc13. I switched to using containers. Trying to salvage my cache now :). Thanks. Will try it out.
<Ablu>
Looks good! Though I apparently cleaned a little too much during my initial attempts. So I guess I will have to rebuild gcc. Anyway. Long lunch break it is then...
<rburton>
give us details, it's hard to debug from "weird"
<rburton>
if your new host has gcc13 then you need the brand new uninative
<rburton>
(you'll note that none of the supported host OSs for the yocto releases have gcc13)
<rburton>
the workaround is to disable uninative
<Ablu>
rburton: http://sprunge.us/a1CVXo was my error. I upgraded to latest Fedora which brought GCC 13.
<rburton>
yeah, disable uninative
<rburton>
no need to trash sstate
<Ablu>
But yeah, since it is not supported as host OS I switched to building in a container.
<rburton>
containers work better :)
<Ablu>
Hm. This is just a smaller project that I had around. All the newer/bigger ones are in the container already. So I guess a rebuild in the container may be the better long-term solution :)
<Ablu>
The TLS cert on wiki.yoctoproject.org expired apparently... Who should be notified about this?
<LetoThe2nd>
Ablu: people have already been notified.
<Ablu>
LetoThe2nd: ACK :)
* sudip
wonders who all are going to be in the Dev day
zpfvo has quit [Ping timeout: 255 seconds]
* LetoThe2nd
will be
<JaMa>
Ablu: or upgrade to uninative 4.0 already in master and on it's way to kirkstone and mickledore - and then let me know if mkfs.ext4 happens to segfault for you :)
* JaMa
won't be
zpfvo has joined #yocto
<sudip>
are we going to have a special corner for people on irc so that we can meet and put a face to irc nicks?
<rob_w>
i am on kirkstone and use my own IMAGE_CMD_TAR where i md5sum all files and place a md5sum.txt on / of the image , that now fails with permission denied .. that was working with a thud chain , any hints ?
<rob_w>
also i did this in my local.conf IMAGE_FSTYPES:remove = "wic ubifs ubi"
<rob_w>
but wic are still created ? any hint for that ?
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
<rburton>
bitbake-getvar -r <imagename> IMAGE_FSTYPES to see what value it ends up with. maybe you've a wic.something being built too.
<rburton>
fwiw, a rootfs post-process hook would probably be a better way of getting a md5 in the image
<rburton>
RP: do you have an opinion on whether meta-clang should be in a-quick or a-full? I'm guessing full.
<rob_w>
rburton: ah thx , IMAGE_FSTYPES comes back like this " tar.xz wic.xz wic.bmap" .. thx !
silbe has joined #yocto
Guest98 has quit [Quit: Client closed]
xmn has joined #yocto
Guest98 has joined #yocto
Xagen has quit [Ping timeout: 260 seconds]
Guest98 has quit [Quit: Client closed]
<RP>
rburton: full
Minvera has joined #yocto
Guest98 has joined #yocto
sotaoverride_ has quit [Server closed connection]
prabhakarlad has quit [Ping timeout: 245 seconds]
sotaoverride_ has joined #yocto
astlep55047 has quit [Remote host closed the connection]
astlep55047 has joined #yocto
Xagen has joined #yocto
<halstead>
TRO[m], Ablu, LetoThe2nd, wiki server cert renewals are unstuck.
<LetoThe2nd>
halstead: thanks!
<Ablu>
halstead: looks good on my end again :). Thanks for fixing!
kscherer has joined #yocto
sakoman has joined #yocto
rob_w has quit [Remote host closed the connection]
<mborzecki>
anyone managed to successfully enable cgroup v2 on kirkstone? I can't try with linux-yocto kernel as I'm forced to use linux-imx, everything is seemingly in place, /sys/fs/cgroup is a cgroup2fs mount, even got /sys/fs/bpf and device controller running, but for some reason a bunch of random devices such as /dev/fb0 spidev* hwrng don't appear, kernel config with and without are almost identical (differing bits are only related to cgroup2), I
<mborzecki>
suspect there's something weird/wrong about udev, but no clue what could that be
<mborzecki>
eh, I'm a muppet, had PACKAGECONFIG += "cgroupv2" and ended up with just cgroupv2 in systemd's PACKAGECONFIG, everything else was dropped
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linex[m]>
hello!
<linex[m]>
I have added a service file to ${D}${sytemd_system_unitdir}/mydir/ and then configured SYSTEMD_SERVICE and SYSTEMD_AUTO_ENABLE but it's apparently not finding the service file !
<rburton>
did you inherit systemd in the recipe?
kpo has quit [Ping timeout: 240 seconds]
<rburton>
obviously guessing what the problem is because "apparently not finding the service file" doesn't describe a problem
<linex[m]>
yes that too :)
<rburton>
explain what the problem is and maybe someone can help
<linex[m]>
I am getting this error and I am not sure why :
<linex[m]>
`ERROR: my-package-1.0-r0 do_package: Didn't find service unit 'my-package.service', specified in SYSTEMD_SERVICE_my-package.`
<rburton>
what is /mydir/ and why
<linex[m]>
to split service files
<rburton>
does systemd support that?
<rburton>
my debian system has no subfolders in /lib/systemd/system, they're all in that directory
<rburton>
which is where the class expects to find them
<smooge>
rburton, linex[m] on Fedora, I see sub-directories in /lib/systemd/system but they follow a specific syntax . like /lib/systemd/system/rescue.target file has an associated /lib/systemd/system/rescue.target.wants which has links to specific things wanted. [The sub dirs are .target.wants or something like /lib/systemd/system/httpd.service.d .
Xagen has joined #yocto
<smooge>
Not sure how much of that is defined by freedesktop.org docs or is a Fedora only setting. However it does look like sub-direc need to follow specific patterns to be reviewed
<smooge>
`In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories.`
AKN has quit [Ping timeout: 240 seconds]
<rburton>
my system has .conf files in the .d directories
<smooge>
I think it looks like the documentation is as clear as mud
<smooge>
later it says 'Along with a unit file foo.service, the directory foo.service.wants/ may exist.'
<rburton>
sure but that's not the actual unit file in that case
<smooge>
yes sorry I wasn't disagreeing with you.. just adding that someone looking in /lib/systemd/system could see sub-directories but they are meant for specific things.
<smooge>
I failed my 'communicate clearly' roll
<rburton>
i'm sure i found a guide on how to install unit files properly somewhere but google is failing me
embetrix has joined #yocto
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #yocto
<embetrix>
Hi, it looks like out of three kernel modules signing is not supported in yocto, is this a known issue ?
<rburton>
zeddii: ^
<zeddii>
IIRC there's something in meta-security, but I don't use it myself. I just know that we do save keys, etc, to the shared artifacts dir.
<zeddii>
the core bbclass avoid stripping the signatures, so it is known to work
<zeddii>
yah. finally found what I was looking for. We have the fragments available to turn it on, so the core has no issues with the support.
rfuentess has quit [Remote host closed the connection]
tgamblin_ is now known as tgamblin
zpfvo has quit [Remote host closed the connection]
<TRO[m]>
Is there any tool that parses testresults.json and convert it to other formats like xunit?
<TRO[m]>
Or lib?
<rburton>
TRO[m]: resulttool
seninha has joined #yocto
<TRO[m]>
can it export to xunit?
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<TRO[m]>
Anything standalone that can evaluate test results?
AKN has joined #yocto
leon-anavi has quit [Quit: Leaving]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
PhoenixMage has quit [Ping timeout: 240 seconds]
PhoenixMage has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
gsalazar has quit [Ping timeout: 240 seconds]
Guest86 has joined #yocto
Guest86 has quit [Client Quit]
kpo has joined #yocto
AKN has quit [Read error: Connection reset by peer]
ptsneves has quit [Ping timeout: 240 seconds]
vermaete has joined #yocto
<vermaete>
linux-firmware is now by far the biggest package on my Yocto build for an Intel platform.
<vermaete>
What's the normal way to make this smaller?
<vermaete>
There seems to be do FEATURE settings in the recipe.
<vermaete>
E.g. I don't need wireless at all, but all drivers are installed for wireless.
sotaoverride has quit [Server closed connection]
sotaoverride has joined #yocto
alessioigor has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
vermaete: don't install linux-firmware, or just install the firmware subset that you need. linux-firmware depends on _all_ of the seperate packages
<vermaete>
yep, thanks. Of course...
<rburton>
you might need to bbappend to split the packaging up a bit more, for your use case
amitk has quit [Ping timeout: 240 seconds]
qschulz has quit [Remote host closed the connection]
alessioigor has quit [Remote host closed the connection]
Thorn_ has quit [Ping timeout: 240 seconds]
wkawka has joined #yocto
<wkawka>
Hi, I added gcc to the image via packagegroup, build ended up succesfully, but gcc is not avaialble on the target image. I am building for rapsberrypi4-64 machine
<wkawka>
What may be wrong here?
<wkawka>
I added gcc, from meta-openembedded, are there anu other recipes for arm specific gcc?
<Guest40>
wkawka "/poky/meta/recipes-core/packagegroup-core-buildessential.bb" should be enough.
car1t has joined #yocto
<wkawka>
i'll give it a try thanks
beroset has joined #yocto
Algotech has quit [Read error: Connection reset by peer]
Algotech has joined #yocto
qschulz has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
florian_kc has joined #yocto
chep has quit [Server closed connection]
chep has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kscherer has quit [Quit: Konversation terminated!]
Soopaman has quit [Quit: Leaving.]
<khem>
IMAGE_FEATURES += "tools-sdk" would get a working toolchain into target image
seninha has quit [Ping timeout: 255 seconds]
<khem>
usually you also want "dev-pkgs" for headers and libs and " and "tools-debug" for gdb etc. and "dbg-pkgs" for debugging info for full on-device dev experience
seninha has joined #yocto
Thorn has joined #yocto
Guest40 has quit [Quit: Client closed]
Net147 has quit [Server closed connection]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Thorn has quit [Ping timeout: 240 seconds]
<marex>
I have a quick question, is there a way to trigger build of both populate_sdk and the image in one bitbake invocation ?
<marex>
like right now, I have to do ... bitbake core-image-base ; bitbake -c populate_sdk core-image-base ... can I do that with one command ?