ChanServ 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 (2021.11) Nov 30 - Dec 2, 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
sakoman has joined #yocto
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Vonter has joined #yocto
xmn has quit [Remote host closed the connection]
camus has quit [Ping timeout: 264 seconds]
camus has joined #yocto
camus has quit [Read error: Connection reset by peer]
hpsy has quit [Ping timeout: 264 seconds]
dev1990 has quit [Ping timeout: 244 seconds]
dev1990 has joined #yocto
camus has joined #yocto
hpsy has joined #yocto
sakoman has quit [Quit: Leaving.]
yates has quit [Quit: rcirc on GNU Emacs 25.2.2]
matthewcroughan has quit [Ping timeout: 246 seconds]
matthewcroughan has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #yocto
WadeBerrier[m] has quit [*.net *.split]
behanw[m] has quit [*.net *.split]
Nate[m]1 has quit [*.net *.split]
PascalBach[m] has quit [*.net *.split]
hmw[m] has quit [*.net *.split]
meck[m] has quit [*.net *.split]
Alban[m] has quit [*.net *.split]
marex has quit [*.net *.split]
zibri has quit [*.net *.split]
zibri has joined #yocto
marex has joined #yocto
camus1 has joined #yocto
hmw[m] has joined #yocto
PascalBach[m] has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
alessioigor has joined #yocto
meck[m] has joined #yocto
Alban[m] has joined #yocto
alessioigor has quit [Client Quit]
behanw[m] has joined #yocto
Nate[m]1 has joined #yocto
WadeBerrier[m] has joined #yocto
Schlumpf has joined #yocto
<JosefHolzmayrThe> qschulz: michelo: what do you think, would it make sense to have this in the manual? Maybe the common tasks section?
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
Schlumpf has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
rber|res has joined #yocto
<coldspark29[m]> Morning, is there something like a U-Boot Matrix channel? I have some questions about FIT images, because I can't seem to boot mine
<JosefHolzmayrThe> coldspark29: U-Boot is on libera afaik, no idea if they have the bridge enabled
<coldspark29[m]> Thanks. I never used IRC before. Seems like so ancient.
<rber|res> coldspark29[m], on which board do you want to use fit images?
<coldspark29[m]> rber|res: On an i.MX8. I used this guide https://www.thegoodpenguin.co.uk/blog/u-boot-fit-image-overview/
<coldspark29[m]> Did everything exactly as in there, but I am getting an error when booting
<rber|res> coldspark29[m], can you post the error on pastebin or something similar?
<rber|res> coldspark29[m], did you use yocto/fitimage class or an SDK and everything manually?
<coldspark29[m]> But the community there doesn't seem to be very active.
<coldspark29[m]> rber|res: This is actually for Android. My job is to exchange our current Android base system with a Yocto base system for flexibility reasons, but before I need to learn a bit about the old solution and also secure it.
<rber|res> coldspark29[m], Hmmm - I would assume that something is overwritten due to choice of you addresses
<coldspark29[m]> The current Makefile creates a uImage with... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bd6c70c2499c47225ac2f94e6214d805eda9d187)
<coldspark29[m]> and then I try to create a FIT image, which I boot.
<coldspark29[m]> rber|res: I was thinking the same thing, but wouldn't know where to get the right addresses from.
<rber|res> coldspark29[m], hehe - the most trusted process in the world of engineering
<rber|res> coldspark29[m], trial and error ;)
<rber|res> coldspark29[m], there you might be lucky and it just works - I think you still need to pass some addresses
zyga-mbp has joined #yocto
<rber|res> coldspark29[m], you are not
<coldspark29[m]> Why is Element opening Wine when I click on the links?
<coldspark29[m]> rber|res: Ah the last link is helpful. I will try that out thanks
<rber|res> coldspark29[m], might be very Toradex specific
<coldspark29[m]> Toradex?
<rber|res> coldspark29[m], I would bundle kernel,fdt,ramdisk in one fit image and load/run this, than you have less issues with addresses
<rber|res> Toradex is a board manufacturer
<coldspark29[m]> rber|res: That is exactly what I am trying. FIT images seem like state of the art. We will have less problems, once we configured it right. Plus you can make one image with different configurations.
banana_smoothie has joined #yocto
rob_w has joined #yocto
<rber|res> coldspark29[m], well you need a use case. The way you do it - fit image and than extracting kernel/fdt/ramdisk is not very useful. You could load each item over tftp as well.
<coldspark29[m]> rber|res: What do you mean? This is for a USB update currently, but it should also be booted from eMMC, of course.
leon-anavi has joined #yocto
<rber|res> coldspark29[m], https://pastebin.com/kD5xdhth
<rber|res> coldspark29[m], I will be slow with my replies now, since I'll deliver a training session
mckoan|away is now known as mckoan
<mckoan> good morning
Schlumpf has joined #yocto
rfuentess has joined #yocto
<mckoan> coldspark29[m]: is there any particular reason why you need to use a FIT image?
<coldspark29[m]> I tried calculating the load address of the FIT image as shown in the NXP post, but the same problem occurs
<coldspark29[m]> <rber|res> "coldspark29, https://pastebin...." <- I am not using imxtract so far. Should I?
Vonter has quit [Ping timeout: 244 seconds]
zpfvo has joined #yocto
<coldspark29[m]> mckoan: Well, I just successfully signed the kernel for authentication with NXP's HAB. Now I should extend this to the ramdisk and I figured the easiest way is to create a FIT image, which I then sign the same way. So first of all I am trying to load the FIT image without secure boot, but even that fails.
<coldspark29[m]> I also want to get into it, because it seems to be the most modern approach.
<coldspark29[m]> And good morning :)
<banana_smoothie> Good morning.
<banana_smoothie> I had a question about the third-party prebuilt python package on saturday. Can anyone help me to solve my issue? :)
kayterina has joined #yocto
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
mvlad has joined #yocto
prabhakarlad has joined #yocto
Vonter has joined #yocto
alex_b has joined #yocto
rob_w has quit [Remote host closed the connection]
tnovotny has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus has joined #yocto
<coldspark29[m]> So I just made it. I took the uImage to create the FIT instead of using the standard Image. I also used arm instead of arm4. It boots now :)
leon-anavi has quit [Quit: Leaving]
mihai has joined #yocto
lucaceresoli has joined #yocto
florian has joined #yocto
hpsy has quit [Remote host closed the connection]
hpsy has joined #yocto
Guest25 has joined #yocto
leon-anavi has joined #yocto
Markus[m]1 has quit [Quit: You have been kicked for being idle]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<Guest25> Hi, I am trying to create a sdcard image (rawcopy of u-boot.bin, boot-partition and rootfs-partition) via .wks.in-file. The resulting .wic-file is not as expected. The alignment in the rootfs-partition is at 1024, even though I used the "--align 4096" option and all files have strange modification dates (March of 2018). Any idea what could have
<Guest25> gone wrong?
prabhakarlad has quit [Quit: Client closed]
<rber|res> coldspark29[m], I guess you have in uImage the baked in address which works
<rber|res> coldspark29[m], but ... uImage and fitImage is not exactly what it was supposed to be ;)
prabhakarlad has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 has joined #yocto
camus1 is now known as camus
mvlad has quit [Quit: Leaving]
mvlad has joined #yocto
banana_smoothie[ has joined #yocto
banana_smoothie has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 244 seconds]
wwilly has quit [Quit: Leaving]
florian_kc has joined #yocto
tre has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
<barath> is there a general rule for when to use DISTRO_INHERIT vs just INHERIT? the mega manual just says that one is "global" while the other "at the distribution level". the mega manual says to user INHERIT_DISTRO_append for enabling icecc for instance.
<barath> I guess one might be distribution specific, but then I dont know what might happen when doing multiconfig builds for instance? I guess it's set for every distro that's built? but then, why not use the "global" INHERIT?
<rber|res> bradfa, I was not aware of INHERIT_DISTRO, but the doc says: INHERIT_DISTRO[doc] = "Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable."
<rber|res> sorry for brarth
<rber|res> barath
<barath> rber|res: 👍️ but that doesn't tell me what "at the distribution level" means compared to "globally", in practice 🤔
Vonter has joined #yocto
<rber|res> barath, but it says "Don't touch"
<barath> yep, but the docs for icecc also say "touch!" :D
<barath> > INHERIT_DISTRO_append = " icecc"
<barath> hence my confusion
argonautx has joined #yocto
* RP has made the mistake of trying to build a non-release libtool in OE. It needs git submodules :(
<rburton> i should rebase slibtool :)
<rburton> and hey, gitsm: works well
<RP> rburton: there is talk of a libtool release so it might be nice to sort our patches out
<rburton> good luck with that
<rber|res> barath I use: INHERIT += "icecc"
camus has quit [Quit: camus]
camus has joined #yocto
<barath> rber|res: yeah I guess either works. just have to make sure that all nodes use the same I assume
<tnovotny> barath: we use site.conf for that purpose (it is designed for it)
<barath> yeah thanks 🙏
camus1 has joined #yocto
tgamblin has joined #yocto
<banana_smoothie[> I'm trying to use a prebuilt shiboken2 package on a basic dunfell release and when I import shiboken2 it returns the following error:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ef9e805c643b96bf5862fdeac1d895b8a94c094a)
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<barath> banana_smoothie: is that on the target? looks like you need to find the yocto recipe which provides that python module, or install pip on the target and fetch it at runtime
<banana_smoothie[> barath: It's on the target. I used an arch and python3.8 compatible package. If I build the python3 on target, I can import this module without any error. Only yocto based python3 throws errors.
<banana_smoothie[> * used an armv7 arch and
<banana_smoothie[> Unfortunatelly there is no recipe for this module, so I had to create one which extract the archive and install it to the target. I patched the python3-manifest.json too, but the issue is not solved, and I have no idea what should I do to use this package with a yocto based python3.
tre has quit [Remote host closed the connection]
<rburton> banana_smoothie[: typically, the solution is to find the source and build it
<rburton> prebuilt binaries are always a pain, as they might like link and version assumptions
vladest has quit [Ping timeout: 252 seconds]
<ad__> from bbappebdm, is it possible to COMPATIBLE_MACHINE += "another" ?
<rburton> yes
<ad__> becourse i tried and seems to fail. Only = "another" works
<rburton> well, COMPATIBLE_MACHINE is a regex, so you need to format it right
<rburton> its not a space-separated list of names, but a single regex
<rburton> a fairly common idiom is to use overrides, COMPATIBLE_MACHINE:mymachine = "mymachine'
<ad__> rburton, thanks !
<banana_smoothie[> <rburton> "prebuilt binaries are always a..." <- I manually built a python3 on a yocto based image and the prebuilt package is worked on that. It only does not work with yocto based python3 🙄
<rburton> you should try and figure out what the difference is. python3 binaries are a bit of a beast, and cross makes it really tricky.
fleg has quit [Remote host closed the connection]
vladest has joined #yocto
<coldspark29[m]> Is there a way to pass arguments to .its files?
<coldspark29[m]> I would like to tell dtc (or mkimage in this case) where to find the images for constructing the FIT
<coldspark29[m]> * the FIT., * Atm the .its file has to be in the same directory as the images, which makes my Makefile kind of messy.
NiksDev has joined #yocto
hpsy has quit [Ping timeout: 260 seconds]
hpsy has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
Guest25 has quit [Quit: Client closed]
Guest49 has joined #yocto
argonautx_ has joined #yocto
argonautx has quit [Ping timeout: 260 seconds]
artri has joined #yocto
jmiehe has joined #yocto
sakoman has joined #yocto
<Guest49> Hi Guys, can I use some "if not cond" override mechanism? Normally I would use "FOO_append_cond" if I want to append when condition is true. But I would be interested in something like "FOO_append_!cond" (append only when condition isn't true). Does something like this exist?
vladest has quit [Ping timeout: 244 seconds]
<JaMa> Guest49: use can use BAR = "something"; BAR:cond = ""; FOO:append = "BAR"
<JaMa> ${BAR}
<fray> alternatively, always append it and add a conditional _remove.. but JaMa's method is pretty common (I've certainly used it) and I prefer it ovr the remove in most cases.
<Guest49> thx JaMa
<JaMa> yes, remove is impossible to undo, so avoid using it unless really needed
<JaMa> anyone seeing incremental builds with meson all failing with:
<JaMa> | Traceback (most recent call last):
<JaMa> | File "/OE/build/luneos-kirkstone/webos-ports/tmp-glibc/work/x86_64-linux/libepoxy-native/1.5.9-r0/recipe-sysroot-native/usr/bin/meson", line 33, in <module>
<JaMa> | sys.exit(load_entry_point('meson==0.59.2', 'console_scripts', 'meson')())
<JaMa> | File "/OE/build/luneos-kirkstone/webos-ports/tmp-glibc/work/x86_64-linux/libepoxy-native/1.5.9-r0/recipe-sysroot-native/usr/bin/meson", line 25, in importlib_load_entry_point
<JaMa> | return next(matches).load()
<JaMa> | StopIteration
<JaMa> | ERROR: meson failed
<JaMa> ?
vladest has joined #yocto
<rburton> would that be the upgrade/egg thing that was mentioned last week on the list?
doq has joined #yocto
<JaMa> rburton: just noticed v2 of that patch and it might be the same, pity it doesn't show the error in commit message
alex_b has quit [Quit: Client closed]
Xagen_ has joined #yocto
camus1 has joined #yocto
Xagen has quit [Ping timeout: 258 seconds]
camus has quit [Read error: Connection reset by peer]
doq has left #yocto [WeeChat 1.9.1]
camus1 is now known as camus
doq has joined #yocto
doq has quit [Client Quit]
Guest49 has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
wberrier has left #yocto [#yocto]
kiran has joined #yocto
kayterina has quit [Quit: Leaving]
NiksDev has quit [Quit: Client closed]
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
roussinm has joined #yocto
<kergoth> fell behind on swat triage over the weekend since my son got a stomach bug and shared it with me (ugh), lot of laying around miserable. going to try to catch up today..
camus1 has joined #yocto
camus has quit [Ping timeout: 244 seconds]
camus1 is now known as camus
Starfoxxes has quit [Ping timeout: 245 seconds]
Guest31 has joined #yocto
chep has joined #yocto
<chep> Hi
Guest31 has quit [Client Quit]
<chep> I'm using opencv in my project and it works fine when I build an image. But when I want the SDK, almost all libopencv_*.so libraries are only in usr/lib/.debug directory
<chep> is there something to configure that behaviour?
paulg has quit [Ping timeout: 244 seconds]
<rburton> chep: try adding opencv-dev explicitly to the sdk
<chep> what is the variable to do that?
<rburton> append TOOLCHAIN_TARGET_TASK
<chep> i'm trying, thx
Starfoxxes has joined #yocto
paulg has joined #yocto
rfuentess has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 245 seconds]
vd has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
argonautx_ has quit [Quit: Leaving]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nucatus has joined #yocto
tnovotny has quit [Quit: Leaving]
<jaskij[m]> Moving to Hardknott, `VIRTUAL_RUNTIME`, same as `PREFERRED_PROVIDER`, are regular variables, not overrides, right?
zpfvo has quit [Quit: Leaving.]
camus has quit [Ping timeout: 244 seconds]
camus has joined #yocto
zpfvo has joined #yocto
mckoan has left #yocto [#yocto]
mckoan has joined #yocto
mckoan is now known as mckoan|away
<smurray> jaskij[m]: I suspect you mean honister, and yes
<jaskij[m]> smurray: nope, Hardknott, only just now upgrading from Dunfell. Thanks.
<smurray> jaskij[m]: I mentioned honister as it requires the syntax change, but hardknott does not (though it'll work there with the backported compatibility)
zpfvo has quit [Quit: Leaving.]
<jaskij[m]> did I misread it that badly? oof
Vonter has quit [Ping timeout: 260 seconds]
lucaceresoli has quit [Quit: Leaving]
nucatus has quit [Ping timeout: 260 seconds]
artri has quit [Read error: Connection reset by peer]
jmiehe has quit [Quit: jmiehe]
camus has quit [Remote host closed the connection]
camus1 has joined #yocto
camus1 is now known as camus
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
roussinm has quit [Quit: WeeChat 3.3-dev]
u1106 has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
zyga-mbp has joined #yocto
dgriego has quit [Quit: Textual IRC Client: www.textualapp.com]
zyga-mbp has quit [Quit: Textual IRC Client: www.textualapp.com]
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
nucatus has joined #yocto
roussinm has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
Guest92 has joined #yocto
d0ku has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
Guest92 has quit [Quit: Client closed]
Guest2197 has joined #yocto
<Guest2197> Hello, i hope this is right place to ask :) I need some advice regarding debug build of yocto (3.1.8). We have several common meta layers meta-java etc... and our own meta layer with several apps/bb. I would like to enable debug build only for our stuff. When I try to set variable DEBUG_BUILD = "1" anywhere, it influences the whole solution -
<Guest2197> kernel etc... Is there some way to enable debug build only for single meta layer? or what would be correct approach to do this? Thanks.
<vd> rburton: when compiling qtwebengine, does bitbake use a single core or multiple cores? (I think gcc is single thread?) I'm trying to compare the AMD Ryzen 7 5700G vs ryzen 9 5950X for OE builds
<RP> vd: gcc is single threaded but make is run with PARALLEL_MAKE
<vd> RP: so basically 2x $number_of_cores objects are compiled at the same time I suppose
<jaskij[m]> except linking, which is a single core bottleneck
<jaskij[m]> and if by chance LTO is enabled, that will take a long time
<RP> vd: in theory
nucatus has joined #yocto
<RP> jonmason, rburton: can I upgrade u-boot now? :)
* RP deliberately didn't do that on the weekend
artri has joined #yocto
<vd> jaskij[m] true for linking. So for the same amount of RAM (let's say 64Go for QtWebEngine) the 5700G 8-core @ 3.8Ghz should provide good performance compared to the 5950X 16-core @ 3.4 Ghz in theory
nucatus has quit [Ping timeout: 260 seconds]
kiran has quit [Ping timeout: 264 seconds]
artri has left #yocto [#yocto]
Guest2197 has quit [Quit: Client closed]
Guest2124 has joined #yocto
<jaskij[m]> vd: if that 5950X isn't boosting to around 4GHz during builds, I'd RMA that PC
<jaskij[m]> Or at least 3.8-3.8
<jaskij[m]> *3.8-3.9
<RP> Guest2124: currently there are no "layer" specific overrides you can use so you'd have to do it in some anonymous python I suspect
<jaskij[m]> vd I'm not going to suggest XMP here (since it's *technically* OC), but hopefully you at least went with 3200 JEDEC memory? It's hard to get AFAIK, but Ryzens are *extremely* memory sensitive. I've seen benches where performance scaled linearly with RAM clock (up to a limit, but it's higher, around 3600-3800).
<jaskij[m]> (don't want to spam here with advice on build machines, feel free to dm me)
<Guest2124> and some "correct" .bb or .bbappend way to do this? :)
<Guest2124> I noticed someone else had same problem today https://stackoverflow.com/questions/69701939/building-yocto-and-specifying-a-layer-to-be-a-debug-build-everything-else-relea , and I guess its quite valid use-case to debug only your development stuff in some future release if its not possible now :)
<jaskij[m]> Any advice on where to start for a relatively easy kiosk mode GUI? I'm reluctant to use Qt with their licensing changes and the direction they've shown. `meta-gnome`?
<rburton> RP probably. Give Jon notice and we’ll quickly add the version being removed if we’ve not managed to remove the version pinning yet. Now I’m off for a few days!
<elfenix|cloud> @jaskij[m] if you can deal with a very soft feature set, you might check out one of the gaming oriented toolkits like DearImGui - great for running simple displays
<RP> rburton: have fun
<rburton> jaskij[m]: Pick a toolkit you know. Gtk has bindings for most languages, or just make a web app
<elfenix|cloud> if you're not dealing with commercial licensing of Qt, there's always the option of LGPL variants
<jaskij[m]> Might've asked it wrongly: I'm thinking from Yocto end, for now, what to set up. Guess if I go with Gnome in kiosk mode, it's entirely up to me which graphical toolkit goes on top of that?
<jaskij[m]> elfenix|cloud: LTS is afaik commercial-only
<jaskij[m]> or did they backtrack on that one?
<RP> zeddii: I'm wondering if we should get rid of the destsuffix git fetcher parameter in favour of the subdir one used by every other fetcher backend
<elfenix|cloud> jaskij[m]: is there a compelling reason to use LTS versus the normal open source release?
<vd> jaskij[m] I'm writing a distro for kiosk ^^ I'm currently using QtWebEngine for a web front-end though.
<jaskij[m]> vd: Web is a no-go for us, unfortunately. We don't have the skills in the team and can't outsource because stupid grant rules.
<vd> jaskij[m] but given all web frameworks out there, a locally hosted web interface could be really simpler to write compared to some UI specific toolkits
<jaskij[m]> vd: with no one with web frontend experience?
<vd> This is a skill easier to get rather than UI specific toolkits IMO
<zeddii> RP: seems reasonable to me. I'm a heavy user of it, but it's an easy update.
<RP> zeddii: I posted a patch on the bitbake list to add support for it. It just seems like a glaring horrible usability issue in the API currently
Guest2124 has quit [Quit: Client closed]
Guest2159 has joined #yocto
florian_kc has joined #yocto
d0ku is now known as dezeroku
<RP> khem: having looked at libtool patches, I started looking at the gdb ones. I'm very surprised upstream haven't done something about some of them :/
<zeddii> RP: the patch reads ok to me. but it is adding / fixing subdir, right ? I didn't see the removal of destsuffix
<RP> zeddii: right, this one just adds it. Removal (or warning) is another level of work
* zeddii nods. I was was going to suggest a warning, but then noticed it wasn't being removed .. yet
<RP> zeddii: I'm left wondering if it is a good idea or not (or do I just send patch changing the existing users?)
<jaskij[m]> <vd> "This is a skill easier to get..." <- Fair. Considering the skills on the team (only desktop experience is C#), I'll probably spend a few days trying to package an AvaloniaUI demo and go on from there. Alternatives are web or Qt.
<zeddii> meta-virt is probably the heaviest user. I can do a conversion without much trouble.
<RP> zeddii: I was asking you as I know you're a heavy user :)
<zeddii> if I'm aware enough of when it is merging, I can do the conversion. I tend to see the patches, and then not track when it actually lands in master :D
Guest2159 has quit [Ping timeout: 256 seconds]
<RP> zeddii: ok, I'll let you know :D
<vd> jaskij[m] "Blazor: Build client web apps with C#" do you know this M$ thing?
<jaskij[m]> looks neat, thanks
vd has quit [Quit: Client closed]
dezeroku has quit [Ping timeout: 244 seconds]
vd has joined #yocto
yates has joined #yocto
nucatus has joined #yocto
<yates> do_install installs built components for each recipe into the recipe's image folder. what task copies/installs those files into the global sysroots-components folder?
<RP> yates: populate_sysroot
akiCA has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
<yates> well duh.
mvlad has quit [Remote host closed the connection]
nucatus has joined #yocto
prabhakarlad has quit [Quit: Client closed]
nucatus has quit [Ping timeout: 260 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
yates has quit [Remote host closed the connection]
xmn has joined #yocto
prabhakarlad has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<zeddii> anyone else seeing some meson based recipes blow up in master ? I updated earlier, and now glib-2.0 and xorgproto-native are failing
tadej has joined #yocto
<fray> there was a patch on the list about meson and empty python eggs? directories
<moto-timo> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=abelloni/master-next&id=925004e613cf1eb62d76fcc00915c89bc711535a
<moto-timo> zeddii: what symptoms are you seeing?
<RP> zeddii: probably the python egg meson issue
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
<zeddii> this is what makes the console: https://pastebin.com/t01239GB
<zeddii> I'm rebuilding a few things now.
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
tangofoxtrot has quit [Ping timeout: 260 seconds]
tangofoxtrot has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
<zeddii> with enough cleanalls on the offending -native packages, it seems to be chugging along now.
florian_kc has quit [Ping timeout: 260 seconds]
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]