ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.11) Nov 29-Dec 1, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<CosmicPenguin> Has anyone else seen a bug where CMAKE doesn't replace _IMPORT_PREFIX in INTERFACE_LINK_LIBRARIES when exporting a package? This is hitting in spriv-tools, /usr/lib/librt.so makes it through untouched
<CosmicPenguin> Hmm - actually, on second thought, it might be because cmake doesn't recognize the absolute path that librt.so lives in
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
florian has quit [Ping timeout: 260 seconds]
<moto-timo> paulg: ha. speak to HomeKit and the other libraries please.
<moto-timo> abelloni: indeed. it . is. not.
<moto-timo> Ok, now I want to do a RealFake Grogu video
<PhoenixMage> *sigh* progress, at least now I am getting Starting kernel then nothin :/ Not sure why it isnt throwing anything to serial after that
<moto-timo> Dear universe, please use all the energy for this AI/ML stuff to simply create amusing Grogu videos on demand.
<abelloni> PhoenixMage: either the kernel is not booting or your console= is not correct
<PhoenixMage> abelloni: Yeah, hopefully the later, the optimistic part of me was hoping it would use the u-boot serial
* moto-timo has wasted many hours on incorrect console=
<moto-timo> It's 2022. Can we just all agree on one /dev/tty as The One? No? Well...
<abelloni> PhoenixMage: it doesn't unless you use earlyprintk
<moto-timo> +1
<moto-timo> verbose, but it sure helps
<PhoenixMage> abelloni: I am using earlyprintk
<fray> well /dev/tty is "the one", after you set console=.. ;)
<moto-timo> fray: /dev/ttyS0? /dev/ttyfsckyourassumptions?
<fray> no.. "/dev/tty" :) Before login and everything else gets in the way..
<abelloni> /dev/console you mean ;)
<PhoenixMage> Is there a straight forward was to work out which ttyS? it is?
<moto-timo> Oh lol. I meant /dev/tty*
<moto-timo> touche
<abelloni> probably not a ttyS unless you are on x86
<fray> /dev/tty SHOULD be your currently displaying tty.. so before the login and other stuff start screwing with the terminal.. /dev/tty is all you need.. it's "the one"... but alas, we have to have multi-user systems and then it all falls apart again
<moto-timo> PhoenixMage: in my experience it can change based on platform (like abelloni said)
<fray> half my ARM systems use ttyS
<abelloni> stop using atmel or ti then ;)
<PhoenixMage> Might boot my armbian emmc and check what they use, cheating for the win
<moto-timo> Even on x86 it was wildly variable in my painful INTC experience
<fray> this is all AMD/Xilinx
<fray> I still have at least one x86 system that doesn't use ttyS
<moto-timo> The BIOS will own you.
<abelloni> ah, then they have 8250 compatible uarts
<moto-timo> Now, shall we talk about SecureBoot and why it isn't even close to standard or normal?
* moto-timo ducks
<fray> or "secure"
kscherer has quit [Quit: Konversation terminated!]
roussinm has joined #yocto
<moto-timo> I do get a chuckle (because I haven't actually touched it yet) about UEFI on arm now being standard
<fray> "standard"
<moto-timo> But DO NOT look at the tianocore code. DO NOT. NO.
<khem> SystemReady is a good effort
<fray> it's a good idea.. but I'm mixed on if it's a good implementation
<khem> I think it could be extended to non ARM systems as well
<moto-timo> khem: I agree, but fsck the EFI code base needs to be chucked in the dumpster and re-written in... rust?
<fray> would likely be better if it was written in Python.. ;)
<moto-timo> all that legacy baggage is just shyte
<khem> yes infact lot of folks are already doing that
<moto-timo> fray: which Python? 3.7? 3.10? 3.11? 3.12? breaking changes all over the place
<khem> I know few projects already rewriting it in rust
<moto-timo> khem: +1
<moto-timo> rust is no magic bullet, but it is newer and has _fresh_ young blood hacking it
<khem> here I have a pet project writing my yoe updater in rust as well 🙂
<fray> I'm just waiting for the first major rust vulnerability (to make the news)
<moto-timo> I am seeking the time/energy to write a rust blog engine for https://moto-timo.dev
<PhoenixMage> hmmm, must be a kernel issue :/
<khem> it is not, it is however a good guardrails for new folks and encourages good programming practices
<moto-timo> PhoenixMage: summarize the symptoms again?
* moto-timo being super lazy
* khem is loving the new arc browser
<khem> Can preview websites from IRC/Matrix
* moto-timo does a search on arc
<PhoenixMage> moto-timo: Just Starting kernel then nothing, setenv bootargs earlyprintk=ttyS2,1500000 console=ttyS2,1500000 console=tty1
<PhoenixMage> doesnt help
<PhoenixMage> (they are the console commands from armbian for the board which *does* throw to serial
<moto-timo> PhoenixMage: that is a very off baudrate, should be... 115200
<PhoenixMage> Its an rk3568 board using mainline kernel 5.19.17 which does have rk3568 support
<PhoenixMage> moto-timo: Its the baud rate u-boot uses
<PhoenixMage> And default for the board I believe
<fray> I've seen some USB FDI's that took strage rates like that...
<fray> but ya, that looks "sus"
<moto-timo> ok, sus
<PhoenixMage> Its the baudrate I am using to interact with u-boot so should be fine
<moto-timo> I can think of several board designs that would flail at that signal rate... but I digress
<moto-timo> PhoenixMage: ok... nm
<moto-timo> Now I wish I had that board or any other in the family
<PhoenixMage> This is a rock 3a
<moto-timo> But... I do have 2 BBAI64, so not going to bitch too much
* moto-timo has over 100 SBCs
<PhoenixMage> I have been chatting to tlwoerner about them
<moto-timo> +1 good to hear that
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<PhoenixMage> Wonder if there is anything I can enable in the kernel config that will help troubleshoot
vvn has joined #yocto
sakoman has quit [Quit: Leaving.]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
marek has quit [Quit: Client closed]
Tokamak has quit [Quit: Tokamak]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<tlwoerner> yes, rockchip boards have been using 1,500,000 baud for quite a few years now as default
Tokamak has joined #yocto
<moto-timo> TIL today
davidinux has quit [Ping timeout: 248 seconds]
prabhakarlad has quit [Quit: Client closed]
davidinux has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 248 seconds]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
olani has quit [Ping timeout: 248 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
goliath has quit [Quit: SIGSEGV]
amitk has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
sgw has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
marek has joined #yocto
olani has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
sgw has quit [Quit: Leaving.]
roussinm has quit [Quit: WeeChat 3.3-dev]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sgw has joined #yocto
davidinux has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has quit [Ping timeout: 248 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
leon-anavi has joined #yocto
amgedr has joined #yocto
sgw has quit [Quit: Leaving.]
xcm_ has quit [Remote host closed the connection]
xcm_ has joined #yocto
jclsn has joined #yocto
Guest50 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mborzecki has left #yocto [#yocto]
mborzecki has joined #yocto
mborzecki has joined #yocto
Schlumpf has joined #yocto
mckoan|away is now known as mckoan
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mthenault has joined #yocto
rob_w has joined #yocto
rfuentess has joined #yocto
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
<mthenault> Hello, we have a build server which saves the sstate-cache between builds but not build/tmp/deploy/images/. The issue is that if a recipe is not being re-built because of caching, there is no re-installation on build/tmp/deploy/images/. Is there a way to force re-installation of recipes even if the build is cached?
sgw has joined #yocto
zpfvo has joined #yocto
zkrx has quit [*.net *.split]
paulg has quit [*.net *.split]
Starfoxxes has quit [*.net *.split]
zwelch has quit [*.net *.split]
ecdhe has quit [*.net *.split]
jjmcdn has quit [*.net *.split]
mrpelotazo has quit [*.net *.split]
svuorela has quit [*.net *.split]
ldericher has quit [*.net *.split]
fray has quit [*.net *.split]
simond47 has quit [*.net *.split]
Ch^W has quit [*.net *.split]
mischief has quit [*.net *.split]
mario-goulart has quit [*.net *.split]
marex has quit [*.net *.split]
perdmann has quit [*.net *.split]
npcomp has quit [*.net *.split]
Ch^W has joined #yocto
perdmann has joined #yocto
fray has joined #yocto
jjmcdn has joined #yocto
ecdhe_ has joined #yocto
zwelch has joined #yocto
mischief has joined #yocto
paulg has joined #yocto
mario-goulart has joined #yocto
ecdhe_ has quit [Changing host]
ecdhe_ has joined #yocto
Starfoxxes has joined #yocto
zkrx has joined #yocto
npcomp has joined #yocto
ldericher has joined #yocto
mrpelotazo has joined #yocto
olani has quit [Remote host closed the connection]
svuorela has joined #yocto
marex has joined #yocto
<amgedr> mthenault: did you try bitbake <recipename> -c cleansstate
florian has joined #yocto
<mthenault> yes, that would work, but for example for the kernel i don't want to re-build it on each build if it is cached. I just want the artifacts..
alessioigor has quit [Quit: alessioigor]
<amgedr> mthenault: if you clean a recipe and run build it would only be rebuild that recipe again in addition to the image files. if you want to rebuild the image only you could run bitbake <imagename> -c clean
alessioigor has joined #yocto
Schiller has joined #yocto
<mthenault> @amgedr: doing -c clean makes me re-build the whole recipe even though i already have it cached, so why cache it at the first time? Example for the linux-qoriq recipe that I have which produces the fitImage artifact that I need each time.
<mthenault> first place*
amitk_ has joined #yocto
<mthenault> i guess the only solution is to save tmp/deploy/images/* alongside the sstate cache
amitk has quit [Ping timeout: 248 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
olani has joined #yocto
mvlad has joined #yocto
<LetoThe2nd> yo dudX
<mckoan> hey LetoThe2nd
gho has joined #yocto
prabhakarlad has joined #yocto
Herrie has quit [Quit: ZNC 1.8.0 - https://znc.in]
GuestNew has joined #yocto
<GuestNew> Hello, it's possible to create one yocto recipe inherited from "module" class for a recursive call ? (I have severals modules in one repo and I don't want to create one reacipe for each module ...)
<LetoThe2nd> GuestNew: you mean, one recipe that provides a number of pacakges?
<GuestNew> LetoThe2nd one package
<GuestNew> but several modules to install
<GuestNew> I have mod1 mod2 modX folders with a Makefile, I'm abale to build modules separately in devshell,
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
gsalazar has joined #yocto
d-s-e has joined #yocto
Herrie has joined #yocto
gsalazar has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
tperrot has quit [Ping timeout: 246 seconds]
tperrot has joined #yocto
Guest13 has joined #yocto
goliath has joined #yocto
<Guest13> hi everyone, im trying to build qt5-kiosk-browser, but while building qtwebengine i get the following error:
<Guest13> | 41 | #include <bits/c++config.h>
<Guest13> using meta-qt5(master) and gcc 11.3. instead of "c++config.h" there is "c++config". could it be caused by this?
<Guest13> "/usr/include/c++/9/cstdlib:41:10: fatal error: bits/c++config.h: No such file or directory"
<svuorela> hmm.. where is the valid version numbers for bitbake recipes defined ?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
GuestNew has quit [Quit: Client closed]
kanavin has quit [Quit: Leaving]
<qschulz> mthenault: remove everything in tmp between builds
<rburton> Guest13: either the recipe or the build system used by qt5-kiosk-browser is broken, it shoudn't be reading from /usr
<qschulz> mthenault: we don't support removing only some parts of tmp, either remove all or nothing. You can have your sstate-cache outside of this directory (same for downloads), see SSTATE_DIR and DL_DIR
<qschulz> mthenault: I personally remove everything from my CI between builds and have sstate-cache and downloads directory on other locations that are permanent
<mthenault> that is exactly what we do as well
<mthenault> as a result, sometimes the fitimage will be in tmp/deploy/images/** sometimes not
<mthenault> depending on if it is getting rebuilt
<qschulz> mthenault: ok, this is an issue in your recipe
<qschulz> I can half-guess that you used to the wrong variable in do_deploy
<mthenault> well, do_deploy does not get re-executed if it is cached
<mthenault> it's linux-qoriq from freescale..
kanavin has joined #yocto
<qschulz> mthenault: not a guarantee it';s done properly :)
<mthenault> :D
<qschulz> mthenault: https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/deploy.bbclass, it needs to be installed in DEPLOYDIR
<marek> Hi, does it make sense to use pip in recipes to install python dependencies or it's not very good idea and what be the right approach? Thanks
<qschulz> mthenault: bitbake-getvar -r linux-qoriq do_deploy
<mthenault> @qschulz: ok.. anyway, I use this workaround: bitbake linux-qoriq -c clean ; bitbake linux-qoriq. This doesn't recompile the whole kernel but do_deploy gets executed
<qschulz> and check the content of the function (or read WORKDIR/temp/run.do_deploy
<qschulz> mthenault: yeah I would spend an hour or two on trying to find out what the issue is
nemik has quit [Ping timeout: 246 seconds]
<mthenault> hm, a bit wierd, there is only run.do_deploy_setscene and run.do_deploy_source_date_epoch_setscene. also bitbake-getvar is not found (I'm on hardknott)
nemik has joined #yocto
<rburton> marek: terrible idea, unless you're packaging an absolutely huge monolithic component
gsalazar has joined #yocto
<mthenault> qschulz: but this mechanism is also true for other recipes. I have a custom recipe with inside do_deploy(): install -m 0644 thefile ${DEPLOYDIR}. If i delete tmp/deploy/images/myimage/thefile and i do bitbake myrecipe, the file doesn't get re-deployed. doing -c clean first fixes it
<marek> rburton: well have some pip handling in recipe which works for dunfell but again breaks in kirkstone :), so just lookin now into proper way, so only proper way is to add all necessary dependencies as python recipes and use them right?
<rburton> i expect it breaks in kirkstone as we disable network outside of fetch tasks by default
<rburton> the proper way is to package all the modules, yes.
<rburton> if you have a huge component with a load of really tight dependencies then just enable networking with the [network] flag, see the docs
<qschulz> mthenault: hardknott is EOL for a while already now, I would suggest to upgrade to kirkstone now which is an LTS
<qschulz> mthenault: in any case, as said, it is not supported to only remove parts of your tmp directory
<qschulz> either you remove all or nothing
<mthenault> ok, thanks for your help
<rburton> mthenault: you can force a deploy with bitbake myimage --cmd deploy --force
gsalazar has quit [Ping timeout: 252 seconds]
<rburton> but yes, don't just delete bits of tmp. bitbake thinks it deployed, so why would it redeploy?
<mthenault> rburton: thx, but this is not an image, just various recipes i need the output of. running do_deploy -f does not work each time. but -c clean and rebuilding does
<mthenault> yeah..
<mthenault> well our build server just imports sstate_dir and dl_dir
seninha has joined #yocto
<mthenault> and the rest is clen
<mthenault> clean*
marek78 has joined #yocto
<marek78> rburton: I enabled network access but then got issue with permission denied in /usr/lib/python3.10 so added custom path for installing pip and this kid of work but from time to time I'm seeing also other issues related to that
<rburton> marek78: you'll need to make a venv and stuff, you can't just 'pip install foobar'
<marek78> rburton: ok, if I'll do it in venv then do I need to set PYTHONPATH to this as some processing require calling binaries (like protoc from some pip installed packages)
marek has quit [Ping timeout: 260 seconds]
<rburton> arguably, there should be a class to just do it properly. give it a package name to install and a location, and off it goes.
<rburton> obviously license and source tracking and everything else goes out the window...
<marek78> rburton: can you point me pls to class name, thx
<rburton> *should* be a class
<rburton> still needs writing
<rburton> it should just be a matter of creating a venv and then pip installing stuff, but obviously the "and i'll just compile something now" would likely break...
<marek78> rburton: ok I see, thanks
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
Guest13 has quit [Ping timeout: 260 seconds]
dsueiro has joined #yocto
Guest13 has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
Guest13 has quit [Quit: Ping timeout (120 seconds)]
marek78 has quit [Quit: Client closed]
sgw has quit [Ping timeout: 260 seconds]
dmoseley has quit [Ping timeout: 252 seconds]
seninha has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
leon-anavi has quit [Read error: Connection reset by peer]
leonanavi has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
<RP> rburton: been playing with storing out all the sig data. If we take the hit of IPC to the main cooker from the parsers, the data is 580MB but compresses down to 17MB
marek has joined #yocto
* RP suspects large memory use but there is a trick we could use for that
dsueiro has quit [Quit: Client closed]
Schiller has quit [Quit: Client closed]
landgraf has quit [Quit: WeeChat 3.5]
landgraf has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
jclsn has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<rburton> nice
Guest13 has joined #yocto
Schiller has joined #yocto
jclsn has joined #yocto
<Guest13> im trying to build qt-kiosk-browser and The build dependency is defined as "qtwebengine".
<Guest13> is it possible that 16gb ram + 16gb swap area is not insufficient when trying to build "qtwebengine"?
<rburton> Guest13: that wouldn't result in the error you pasted
<Guest13> thanks to you, i know it's not related to the error im getting. i just wanted to ask.
<rburton> webkit is huge but might build with that much
<svuorela> Guest13: that might be enough. What arch are you buildin on ?
<svuorela> do you have a 64bit linker ?
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<Guest13> svuorela im new to yocto, i didn't quite understand what you said, but im trying to get a build for the armv7l architecture.
Schlumpf has quit [Quit: Client closed]
zpfvo has quit [Quit: Leaving.]
gsalazar has joined #yocto
zpfvo has joined #yocto
mthenault has quit [Quit: Leaving]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Guest13 has quit [Quit: Client closed]
rob_w has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dmoseley has joined #yocto
ramacassis[m] has joined #yocto
kscherer has joined #yocto
d-s-e has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<tlwoerner> o
<tlwoerner> (oops)
<tlwoerner> i'm curious to know if anyone has sound working from a qemu image (runqemu)
roussinm has joined #yocto
<tlwoerner> i played with it off and on over the last day or so. i finally have qemu showing up in my host's audio mixer
<tlwoerner> so that's progress
<tlwoerner> the current sound settings in the qemu config file are obsolete and i'm trying to find the right incantation to make qemu happy
frieder has joined #yocto
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
xmn has joined #yocto
<ramacassis[m]> hi, is there a case where putting a .bb and .bbappend in the same layer is justified ?
<ramacassis[m]> for instance, the project I'm working on used to build nginx_1.17 from meta-webserver (dunfell)
<ramacassis[m]> To get an upgraded version they took the nginx folder from kirkstone (with an nginx_1.21 recipe), and copied it to a new "meta-project" (with a higher priority).
<ramacassis[m]> and finally added a nginx bbappend, still in meta-project to add specific files (and not alter the initial recipe)
<ramacassis[m]> are there better ways to differentiate the upstream recipe from the local changes ? maybe with just with a README and comments in the recipe ?
<ramacassis[m]> tlwoerner: never tried sorry... hope you'll get some feedbacks
amgedr has quit [Quit: Leaving...]
marek has quit [Quit: Client closed]
dmoseley has joined #yocto
<ramacassis[m]> * are there better ways to differentiate the upstream recipe from the local changes ? maybe with just with a README file + comments in the recipe ?
Schiller has quit [Quit: Client closed]
<vvn> My product is based on kirkstone (which ships systemd 250) but I need systemd 251 which includes several changes I need. What is the cleanest way to bump? Overriding SRCREV:pn-systemd and SRCBRANCH:pn-systemd in my distro conf?
<Saur[m]> @vvn: If the recipe differences are small for the updated versions, personally I prefer to create a versioned .bbappend, which sets `PV`, `SRCREV` or `SRC_URI[sha256sum]`, and any other necessary changes. The benefit of using a versioned .bbappend is that when upstream eventually updates, I get a build failure and can either remove the .bbappend as it is no longer needed, or update it as necessary to match the new upstream recipe.
michael_zks[m] has joined #yocto
dmoseley has quit [Ping timeout: 255 seconds]
<vvn> Saur[m]: that is indeed a way better approach, exactly what I was asking for. Thank you!
nemik has quit [Ping timeout: 268 seconds]
<vvn> what's the best place to ship systemd .network files? systemd, systemd-conf, systemd-machine-units, or a custom package?
nemik has joined #yocto
dmoseley has joined #yocto
Schiller has joined #yocto
florian_kc has joined #yocto
<rburton> vvn: custom package
alessioigor has quit [Quit: alessioigor]
Schiller has quit [Client Quit]
Guest7752 has joined #yocto
Guest7752 has quit [Client Quit]
Lumpi has joined #yocto
Lumpi has quit [Client Quit]
<vvn> rburton: I feel like systemd-machine-units isn't really useful, don't you think?
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
<vvn> I mean it always sounds like the go-to place to drop in custom unit files, but always end up being a bad choice
Tokamak has quit [Ping timeout: 260 seconds]
RobertBerger has quit [Remote host closed the connection]
prabhakarlad has joined #yocto
zpfvo has joined #yocto
<mcfrisk> hi, any docs or hints or videos about setting up qemu images and running test against them? runqemu works with my image, it boots, can login over serial, can also ssh into the image with userspace networking so localhost:2222 has the target port 22 for ssh. Still, qemurunner.py is failing at "do_testimage: Couldn't get ip from qemu command line and runqemu output!"
<rburton> mcfrisk: have you set the QB_ variables for networking like the qemu machines in core?
Guest50 has quit [Quit: Client closed]
<mcfrisk> rburton: not for networking as I'm using userspace networking with "slirp" everywhere
<mcfrisk> local.conf has: TEST_RUNQEMUPARAMS = "slirp nographic novga"
ecdhe_ has quit [Ping timeout: 248 seconds]
<qschulz> vvn: I would definitely import all bb/inc/files related to the new systemd recipe from a newer recipe (if there's one) otherwise create one. Just editing the version and changing things here and there by using a bbappend destined for another version is going to be a nightmare for users to debug
zpfvo has quit [Ping timeout: 260 seconds]
d-s-e has quit [Quit: Konversation terminated!]
rfuentess has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
mckoan is now known as mckoan|away
olani has quit [Ping timeout: 260 seconds]
gsalazar has joined #yocto
gho has quit [Quit: Leaving.]
cperon has joined #yocto
zpfvo has quit [Remote host closed the connection]
<cperon> Hi there, do you know if it's possible to check if a SRCREV is equal to a tag to be sure that we bump both?
<cperon> I tried to use SRC_URI="git://XXXX.git;tag=1.2.3" but no success :(
PhoenixMage has quit [Ping timeout: 248 seconds]
PhoenixMage has joined #yocto
<kris> Are there any indications yet of what the next LTS Linux kernel version will be?
gsalazar_ has joined #yocto
<cperon> kris: could be 6.4 but no indication yet
gsalazar has quit [Ping timeout: 260 seconds]
PhoenixMage has quit [Ping timeout: 260 seconds]
gsalazar_ has quit [Remote host closed the connection]
<cperon> Ho sorry missed that 5.19 is not a LTS : https://www.phoronix.com/news/Linux-6.1-Likely-LTS
PhoenixMage has joined #yocto
gsalazar_ has joined #yocto
<kris> cperon: Thanks
prabhakarlad has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
Tokamak has joined #yocto
amitk_ has quit [Ping timeout: 260 seconds]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 260 seconds]
Tokamak has quit [Remote host closed the connection]
Tokamak has joined #yocto
gsalazar_ has quit [Quit: Leaving]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
leonanavi has quit [Quit: Leaving]
michael_zks[m] has quit [Quit: User was banned]
<qschulz> cperon: there's an issue with annotated tags since they are of a different hash than the "code hash"
olani has joined #yocto
<qschulz> cperon: I guess there exists some git-foo to check if a commit hash is represented by a tag, probably git describe or something like that
<fray> Seeing if anyone has an opinion. I'm working on tryign to cleanup the graphics implementation on the meta-xilinx layers. I'm currently contemplating a MACHINE_FEATURE that says if the part has a mali or not, then a second DISTRO_FEATURE that says to use libmali (instead of the default mesa lima). Does this seem like a reasonable combination?
sakoman has quit [Quit: Leaving.]
jetm has joined #yocto
<jetm> Hi, does Yocto support a shared-writable cache directory with sstate and downloads directories in a machine when users can execute multiple builds simultaneously?
<jetm> I have read the documentation and some blogs on how to use a share state and downloads directory, but I have not found a source saying if it is supported users building at the same time using a shared and writable directory with all (sstate & downloads) Yocto cache files
aleblanc[m] has joined #yocto
<cperon> qschulz: there is indeed a gitver.bbclass in meta-oe but nobody use it :(
<cperon> i shoul something like inherit gitver and then check than GIT_TAGADJUST = PV right ?
florian_kc has joined #yocto
sakoman has joined #yocto
<cperon> nobody seems to use GIT_TAGADJUST nor GITVER :( anyway will try to add a check with this thanks for pointing out :)
prabhakarlad has joined #yocto
tortoise has joined #yocto
Tokamak has quit [Quit: Tokamak]
prabhakarlad has quit [Quit: Client closed]
sr2 has joined #yocto
<sr2> hi. why bitbake dont allow me to install firmware? `install -m 644 ${WORKDIR}/m4_main.elf ${D}${nonarch_base_libdir}/firmware/` `QA Issue: Architecture did not match (ARM, expected AArch64`
<sr2> its not supposed to match host arch. its firmware for coprocessor
<rburton> Sr2: look up INSANE_SKIP in the manual
<sr2> rburton thank you
jclsn has quit [Quit: WeeChat 3.7.1]
jclsn has joined #yocto
<tortoise> is there any difference between having including weston via IMAGE_FEATURES += "weston" vs putting the packagegroup-core-weston in IMAGE_INSTALL ?
Tokamak has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
<rburton> tortoise: the former is literally the latter
<rburton> FEATURE_PACKAGES_weston = "packagegroup-core-weston"
<tortoise> thanks, still getting used to yocto, going to grep now for the FEATURE_PACKAGES definitions
<rburton> tortoise: core-image.bbclass
sr2 has quit [Quit: Client closed]
<RP> JPEW: Looks like we can get the sigs data for OE-core down to 62MB of pickled data which compresses to 12.5MB (compared to 581MB of json compressing to 17MB)
<JPEW> That's the whole parsing cache?
rsalveti has quit [Quit: Connection closed for inactivity]
<JPEW> Err, I mean thats the sig data for everything, not per-recipe?
<RP> JPEW: that is the siginfo file for every task for every recipe in OE-Core
<RP> well, the data you could build the sig with
<JPEW> RP: Ya, that's very cool.... seems like that would be really useful for post-mortem debugging
<RP> JPEW: the pain point left is getting the data from the parsing threads to the central process to save out. Something to ponder tomorrow
<RP> and somehow syncing this with the main cache
* RP just has a crazy thought. I wonder if we could actually write out the whole data store and just "be done with it"
<RP> If we can compress it into memory/disk well enough...
sr2 has joined #yocto
jamestperk has quit [Read error: Software caused connection abort]
jamestperk has joined #yocto
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 260 seconds]
nohit has quit [Read error: Software caused connection abort]
nohit has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Tokamak has joined #yocto
Tokamak_ has quit [Ping timeout: 252 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
Tokamak has quit [Quit: Tokamak]
kevinrowland has joined #yocto
prabhakarlad has joined #yocto
kscherer has quit [Quit: Konversation terminated!]