<yates>
regarding sysroot population and the tmp/sysroots-components, what if a package reported in a task's "NOTE: Installed into sysroot:" log is under more than one subdirectory of tmp/sysroots-components?
<yates>
or is that arranged so that it never happens? (looks like it)
<yates>
and what is the tmp/sysroots-components/<some-foldr>/<some-sysroot-folder>/sysroot-providers used for? it looks like some "keyng" mechanism, but i don't quite get it
<yates>
are most people east of the U.S.?
<moto-timo>
yates: we’re global, but historically a lot of folks have been EU
<moto-timo>
I’m pacific time zone
<yates>
i see
<yates>
still early for you, then...
<moto-timo>
If 7pm is early
<moto-timo>
To me that’s 12+ hours into my day
_whitelogger has joined #yocto
<yates>
i'm EST, and I started roughly the same time. but i've had lots of breaks...
<yates>
this "work-from-home" paradigm has made my schedule quite crazy!
<yates>
and being 63 i can't seem to sleep a full 7 or 8 hours anymore..
sakoman has quit [Quit: Leaving.]
gioyik has quit [Ping timeout: 276 seconds]
tlwoerner has quit [Ping timeout: 260 seconds]
tlwoerner has joined #yocto
tlwoerner has quit [Client Quit]
tlwoerner has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
nsdrude[m] has joined #yocto
nsdrude[m] is now known as hereiam[m]
Vonter has quit [Ping timeout: 268 seconds]
zeddiii has joined #yocto
zeddii has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
zeddiii has quit [Ping timeout: 265 seconds]
ThomasD13 has joined #yocto
gioyik has joined #yocto
agrue has quit [Ping timeout: 268 seconds]
agrue has joined #yocto
tre has joined #yocto
<JosefHolzmayr[m]>
yo dudX
Tyaku has joined #yocto
leon-anavi has joined #yocto
frieder has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
rfuentess has joined #yocto
<JosefHolzmayr[m]>
any pointers on how to actually get the public sstate mirror to kick in? i'm tinkering around for demonstration purposes, and even on a completely unmodified dunfell build, not a single hit appears.
Guest27 has joined #yocto
gioyik has quit [Quit: WeeChat 3.1]
<JosefHolzmayr[m]>
even when checking out the 3.1.10 tag and setting the path accordingly, i get found 3 - missed 1148
<RP>
JosefHolzmayr[m]: You need master with that variable I mentioned
<JosefHolzmayr[m]>
RP: you mentioned something? where?
<RP>
JosefHolzmayr[m]: It doesn't work with dunfell as there is no read only hash equivalence data to match (except there is no, it just can't work with dunfell)+
<RP>
s/no/now/
<JosefHolzmayr[m]>
RP: ah missed that one. my bad. so this essentially means that after the hashequiv server has been turned on, all prior usecases have been invalidated. correct?
manuel1985 has joined #yocto
<RP>
JosefHolzmayr[m]: since we enabled it, it did stop sstate working from the AB until we had this as well
<JosefHolzmayr[m]>
RP: okay, i think i got it. just trying to understand the current situation (as i can't show/tell/explain things that i don't at least have a basic grasp of myself)
gsalazar has joined #yocto
xmn has quit [Quit: ZZZzzz…]
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #yocto
<JosefHolzmayr[m]>
RP: it seems to work now, thanks.
<RP>
JosefHolzmayr[m]: np, trying to help :)
prabhakarlad has joined #yocto
<JosefHolzmayr[m]>
13 minutes core core-image-minimal. not bad.
<mckoan>
JosefHolzmayr[m]: sounds great. Are you going to discuss it in the next Twitch?
<JosefHolzmayr[m]>
mckoan: don't think so
<Tyaku>
Hi, I come again about my libraries issues. I have a recipe A that provide a static library (.a) and header files. (The header files appear in workdir/sysroot-destdir/usr/include/matter and library in workdir/sysroot-destdir/usr/lib). The recipe B arrive to build using the library of recipe A, but now my problem is when i set "#include 'file'" in the sources of recipe B) "No such file or directory".
<Tyaku>
On the CMake project of recipe B, i have include directories set as "/usr/include/matter"
<qschulz>
Tyaku: I assume the CFLAGS/LDFLAGS/CXXFLAGS/CPPFLAGS/whatever that are passed by Yocto aren't used in your cmake or overridden by it
<Tyaku>
And during the build, I see the "-I/usr/include/matter"
<qschulz>
Tyaku: yeah, that's most likely incorrect
<Tyaku>
But I think it search on "computer" paths (not sure).
<qschulz>
yup looks like it
<Tyaku>
So the correct way is not to define the include directories in the CMakeList.txt, but in the recipe ?
<Tyaku>
With the variables that you said
<qschulz>
use whatever the build system is giving you
<JosefHolzmayr[m]>
Tyaku: the key is to not have the include pathes absolute, but having them automatically determined so that the outer build environment can adjust them as needed.
<olani[m]>
Or use -I=/usr/include/matter if you have to do it like that. The = is replaced with whatever is given to gcc as sysroot and ignored otherwise. I would not recommend it as the preferred solution, but it works.
<JosefHolzmayr[m]>
olani: interesting "dirty" trick, but agreed, absolutely not recommened, at least not without extensive comments explaining it.
<Tyaku>
Currently during the build it use -I/usr/include/matter and it still don't find the files, but as qschulz said, i think it search on "host computer" directories instead of the "/usr/include/matter" in Yocto dirs
<olani[m]>
Josef Holzmayr (TheYoctoJester): Sometimes you have makefiles that have to work in several build environments and pkg-config is not available.
<JosefHolzmayr[m]>
olani: yeah i completely agree. but the '=' character is so hard notice and so little revealing in itself that i would request the maintainer to have an extensive comment right next to it, if the process actually depends on this behaviour.
<mckoan>
JosefHolzmayr[m]: therefore would you mind sharing the local.conf you used to test it ?
camus1 has joined #yocto
<olani[m]>
Tyaku: The "correct" way would be to install a pkg-config file from recipe A and use whatever CMake uses to read such files to find the correct paths.
<Tyaku>
olani[m] Jesus, it's terrible, when I search on internet I don't find examples about these basic things: A recipe that build using a library + headers from another recipe using CMake.
<JosefHolzmayr[m]>
yeah the main source for your headaches is probably that you wrangling two sides in one. i' suggest to first make a recipe that uses some random, already existing library. and then, in a second step, make a recipe that mimics the library behaviour with your own.
<Tyaku>
Did someone know how to generate .pc files (for pkg-config) on yocto ? The docs says: "The pkg-config class provides a standard way to get header and library information. This class aims to smooth integration of pkg-config into libraries that use it.
<Tyaku>
During staging, BitBake installs pkg-config data into the sysroots/ directory. By making use of sysroot functionality within pkg-config, this class no longer has to manipulate the files."
<Tyaku>
So is it supposed to be automatic if we just inherit from pkgconfig ?
<olani[m]>
That inherit only ensures that the native pkg-config tool is available to your build.
<olani[m]>
The files should be installed to /usr/lib/pkgconfig. If you do this right the pc file will be included in the sysroot for dependent recipes.
<Tyaku>
My first project is not CMake based, only the second that use the library :/
<Tyaku>
So, for the first step, I just have to put the .pc in the folder of my recipe where I put "external files / patches". Then just inherit "pkgconfig" and the job should be done ? I see the pkgconfig.bbclass and it seems to create the pkgconfig directory (but i'm not sure).
<olani[m]>
The pc file has to be installed to ${D}${libdir}/pkgconfig in recipe A. It should then automagically be available in the sysroot of reciepe B.
<olani[m]>
You only need to inherit pkgconfig in recipe B
<Tyaku>
In workdir/image or workdir/sysroot-destdir I don't have the folder with pkgconfig file.
<olani[m]>
Which recipe?
<olani[m]>
If it is not in recipe A workdir/image you have not installed it correctly
<olani[m]>
pc-files are handled as header files in the way that they are not bitbake files but files that are part of the package build.
<olani[m]>
The pkgconfig.bbclass file that I use do not install any pc-files
<Tyaku>
Nop, Let me check my local file ..
<Tyaku>
I'm using hardknot, but i'm looking the content to see if it differs
<olani[m]>
I'm also on hardknott and my pkgconfig.bbclass is only a single line
<Tyaku>
Yep me too
<Tyaku>
>_<
<Tyaku>
Ok, so i'm going to manualy configure it.
<Tyaku>
install*
<olani[m]>
I would do all of that in the project makefile. Then you can also make sure that the paths in the pc file matches the paths where the headers and libs are installed. GNU coding standards say (paraphrased) that pc-files should be generated at the install stage so they always match the values of $prefix and so on used at make install.
<rburton>
Tyaku: pkgconfig.bbclass simply pulls in a build dependency, it doesn't know (and cannot) know how to install pkgconfig files
goliath has joined #yocto
<Tyaku>
Currently it didn't work during the build of recipe B, because find_package() is looking for .cmake files (different structure from .pc), after some research find_package() don't use the .pc files, we have to use pkg_check_modules() or pkg_search_module() instead. But as I understand the objective of this is *just* to set the includes/cflags/... as defined in the configuration file provided by Receipe A (the
<Tyaku>
library recipe). But for my initial problem, not sure it will change something because I had in my CMakeList the include directories configured to /usr/include/matter, The files I'm looking for exists in this (workdir/image and workdir/sysroot-destdir), during the build it was not finding the header file because I think it search on computer folder.
coldspark29[m] has joined #yocto
mckoan is now known as mckoan|away
<Tyaku>
Well... I find the correct include folder: "-I${STAGING_DIR_TARGET}/${includedir}/matter"
<olani[m]>
Using pkgconfig files will help you with those paths. Or you can use the -I= flag I mentioned above.
<Tyaku>
Yep, But only if the .pc file use the correct directory (so not /usr/include/matter, but with ${STAGING_DIR_TARGET}). I think I will see how to integrate pkgconfig but later. Currently I focus on building a software that use a library.
<rburton>
Tyaku: what is the library you're building?
<rburton>
hilarious/tragic that a corporate sponsors library designed to be used everywhere is so tricky to build/integrate
<Tyaku>
Currently I think it's not their objective to make a library "easy to use".
<qschulz>
rburton: have you checked the companies in the alliance? I am not surprised.. AT ALL :)
<rburton>
qschulz: one glorious day they'll catch up
<rburton>
(i'm not surprised *at all*
<Tyaku>
This library use the GN build system witch is not realy supported by yocto yet, so just for it, i had to pass by a gn.bbclass that a good guy made. (based on chromium in meta-browser but yeah)
<Tyaku>
Why GN build system ? That's the question, maybe because of Mr Google.
<rburton>
its less how to build the actual stuff, it's more the integration after that
<rburton>
it should be installing things like pkgconfig files, cmake files, something
Guest27 has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
Belsirk has joined #yocto
Guest27 has joined #yocto
rfuentess has quit [Remote host closed the connection]
Ad0 has quit [Ping timeout: 265 seconds]
zeddii has joined #yocto
Ad0 has joined #yocto
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<Tyaku>
If my library from receipe A have a lot of directories for includes and i want to put their content in /usr/include/matter, is there a recursive syntaxt to create folder & install files ? I'm sure this is not the good way: https://pastebin.com/5tattJin
xmn has quit [Ping timeout: 240 seconds]
nerdboy has quit [Ping timeout: 265 seconds]
<Tyaku>
The include folder need to keep the same hierarchy as the rest ..
<rburton>
Tyaku: doesnt matter have an install function for that
<Tyaku>
Matter is not made to work with yocto directly.
<rburton>
this isn't yocto-specific
<qschulz>
Tyaku: probably better to tweak the cmake of CHIP/matter/gn to install to the includedir of your choice
<rburton>
software being able to install is a fundamental thing
<Tyaku>
And the only tutorial about building matter exemples/lib/.. for yocto are using the toolchain.
<rburton>
ok the building documentation has made me laugh/cry
<Tyaku>
matter/chip use GN. I can check how to do this
<rburton>
they appear to assume that you're building on-target, not installing, and just linking directly against the build tree
<rburton>
which is frankly terrifying
<Tyaku>
Yes, the project is mainly "building from target" or you can cross-compile (in exemple folder)
<rburton>
the shortcut for recursive install is mkdir -p. which creates all parents if needed. ie mkdir ${D}${bindir} will make ${D}/usr before ${D}/usr/bin
<qschulz>
rburton: install -D does this too IIRC
<rburton>
yeah, or that
<rburton>
as this is terrible build infra i'd honestly say if it saves you time, cp -r and chown root:root afterwards.
<rburton>
(i'd normally say never do that)
<qschulz>
mmmm install -d does too: "treat all arguments as directory names; create all components of the specified directories"
<qschulz>
so whatever :p
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<olani[m]>
Tyaku: Your not supposed to need STAGING_DIR_TARGET in the pc file. But maybe there is something in your package that defeats the OE setup.
<Tyaku>
olani[m]: Currently I don't use .pc file (i focussed on building my software, I will see this later). So currently in the recipe B I set TARGET_CFLAGS with -I${STAGING_DIR_TARGET}/${includedir}/matter
<Tyaku>
Just for information, I succesfully arrived to build and helloword app, that use the library and some includes from recipe A (chip/matter) and call a function from this library to display some logs.
<olani[m]>
Tyaku: That's fine, I just thought you said you needed STAGINIg_DIR_TARGET in the pc file above.
<Tyaku>
Ok, But what I did is not good: 1. Because i only installed the includes from directories that i need to run the helloworld... 2. Because i have to do this install process directly in the recipe ... (as rburton remark, there is an issue to do it directly in CHIP GN Build system). 3. I don't use pkg-config.
<rburton>
matter doesn't set a pkgconfig file, so ignore that
<olani[m]>
Yeah, I did not realize that this was a package that was not your own. I'd say having install statements in the recipe is fine in this case.
<olani[m]>
Have you tried using #include <matter/header.h> instead of using -I flags?
mihai- has joined #yocto
mihai- has quit [Remote host closed the connection]
mihai has quit [Read error: Connection reset by peer]
bunk has quit [Ping timeout: 252 seconds]
Guest27 has quit [Ping timeout: 256 seconds]
<Tyaku>
olani[m]: There is no such file, but in fact I put 4 include_directories because I don't control how the elements are included. In libCHIP.a, there are files where the #include start from "src" folder, sometimes it's from "lib" folder, sometimes it's from a generated folder [..]
<olani[m]>
Tyaku: header.h was just an example. If you install the files to /usr/inlcude/matter it should be possible to #include them with matter/ prefix. That way you get nice namespacing and do not need the -I-flag
zyga-mbp has joined #yocto
<rburton>
personally i'd be asking the matter support channels how you're meant to install it
bunk has joined #yocto
bunk has quit [Client Quit]
Tyaku has quit [Quit: leaving]
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
frieder has quit [Ping timeout: 268 seconds]
frieder has joined #yocto
<user_123>
Hi
bunk has joined #yocto
<user_123>
I have one question regarding usage of sharepoint/one drive in Yocto instead of ftp links
<user_123>
How to use share point sharepoint OR ondrive links in yocto
<user_123>
and store the supporting file for image build in these
whuang0389 has joined #yocto
<ThomasD13>
Hi, maybe a dumb question: When I create my own machine configuration, is it possible to specify there the kernel which should be used? I would like to get away from all the kernel-recipes of my vendor TI
<JPEW>
We are seeing a problem where a packagegroup doesn't rebuild when a package it pulls in bumps major versions; this causes it to look for the old library version when restored from sstate (e.g. libfoo0 when the new one is libfoo1) and causes a build failure. Does this sound famililar?
<JPEW>
It seems like it might have been fixed in a more recent version of Yocto and I'd like to backport the fix but I cannot seem to find it
<ThomasD13>
thanks qschulz! A second question: The vendor add a lot of patches and config fragments for their kernel version. Can I somehow prevent the application of these patches via my own (maybe with higher priority) layer? Is that a "clean" way to do it?
<manuel1985>
Hello all. I intend to runqemu with kernel parameters supplied using bootparams=. Then I have systemd service which starts the ptest tests when the condition is fulfilled. Basically, on my devmachine I want to do a "kas shell -c runqemu bootparams=runtests kas-config.yml" and have qemu boot up and run the tests.
<manuel1985>
What are your opinions? Are there better ways to do this?
<manuel1985>
Is there existing functionality I can leverage?
vd has quit [Quit: Client closed]
<qschulz>
ThomasD13: if you use a differnet kernel recipe, the patches and config fragments won't apply to your new recipe
<qschulz>
ThomasD13: if we're talking about vendor-kernel-specific changes to non-kernel recipes, I think you better start from scratch and ditch your vendor layer and start your own :)
<Tyaku>
I'm watching webbinar :)
<tlwoerner>
wow, this is pretty stupid. i'm trying to register for ndec_ and JosefHolzmayr[m] talk, but because my company's name isn't in their preset dropdown list, it won't let me register
vd has joined #yocto
<tlwoerner>
so in order to register i'll have to pick a name of a company that i don't actually work for, one that's in their prepopulated list
<tlwoerner>
i chose "yocto project" ;-)
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 252 seconds]
<ndec_>
tlwoerner: heh..
dmoseley has joined #yocto
sakoman has joined #yocto
<ThomasD13>
qschulz, thanks, I have to think about it. Not sure which mess is less :)
<qschulz>
ThomasD13: it all depends how much you need from the vendor BSP layer. Usually it's machine conf file, kernel, and bootloader stuff. Those you can manually import in your own layer
<fray>
the case on the right looks a lot like someone turned on the static user id code
<fray>
but it's not on, one ht left
* RP
suspects an sstate hash issue with the static-group/passwd files from meta-selftest
<fray>
lol, there we go.. has static group/passwd seems odd
<RP>
fray: perhaps the task checksum isn't accounting for that being turned on
<fray>
maybe, I hadn't thought of that..
<RP>
fray: the selftest static files use 522 as the number
<fray>
looks like anon pthing is updating the configs. So maybe this is hiding it from the hash processing
<fray>
'er.. anon python
<RP>
hmm, I'd expect the code to be able to see the result
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
troth has joined #yocto
koty0f has joined #yocto
bunk has joined #yocto
vd has joined #yocto
<vd>
do you usually find conf fragments in conf/include/* or does it have to be specific like conf/distro/include?
dmoseley has joined #yocto
<RP>
vd: depends on the context
mranostaj has quit [Ping timeout: 268 seconds]
<vd>
RP: I'm customizing the build, like adding OVERRIDES, changing IMAGE_LINK_NAME and a few other things based on BB_CURRENT_MC for various multiconfig. It is currently in the distro, but it doesn't feel right
dmoseley has quit [Ping timeout: 260 seconds]
<RP>
vd: those do sound like distro things
<RP>
rburton, JPEW, sgw: Could someone have a look at and ack "create-spdx.bbclass: Search all license directories for license" please?
<vd>
RP: like setting IMAGE_LINK_NAME "${IMAGE_BASENAME}" so that it's simpler to reference (and embed) an image into another. Where would you put such configuration? conf/distro/include/mybuild.inc?
<vd>
(IMAGE_LINK_NAME = *)
<RP>
vd: it is part of your distro setup
<RP>
I mean you can put it where you like but it is really distro config
<vd>
ok. I was a bit confused with the fact that image/machine/distro must be orthogonal, I felt like I couldn't easily test another distro like poky with my images, but I guess flexibility has its limits
<vd>
what I mean is that by referencing IMAGE_LINK_NAME (thus IMAGE_BASENAME) in my image recipes, they kinda become distro specific, but well you're right it's part of my distro anyway.
<RP>
vd: your images are probably strongly tied to your distro but as you say, at some point it isn't generic
<vd>
indeed
mranostaj has joined #yocto
<vd>
especially since they do require to inherit a few class, which makes them even less generic
* vd
says goodbye to core-image-minimal
<vd>
The meaning of "distro" in OpenEmbedded is often a concern, I guess one must see it more as a "build" configuration in fact.
dmoseley has joined #yocto
<RP>
distro is the policy/configuration effectively
dmoseley has left #yocto [#yocto]
<RP>
kanavin: how are the deprecation fixes looking?
<vd>
so "ideally" image/distro/machine should be orthogonal, but it's rarely the case in the real world, right?
<JPEW>
vd: You can keep them pretty orthagonal... it can take a little work though
<RP>
vd: it definitely can be done, it likely just isn't worth it to you for your images
<vd>
ok, thanks a lot.
<kergoth>
I wouldn't go as far as to say it's rarely the case. Fairly common for new users to take shortcuts in that area until/if they realize the benefits of it, however
<JosefHolzmayr[m]>
RP: concerning the sstate thing from earlier - should qemu also be pulled?
<RP>
JosefHolzmayr[m]: depends if your configuration matches what the autobuilder builds
<JosefHolzmayr[m]>
RP: hmmm
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
dmoseley_ has joined #yocto
<JosefHolzmayr[m]>
seems i missed the assume provided for libsdl2
dmoseley_ has quit [Client Quit]
manuel has joined #yocto
<manuel>
Hi all! I'm creating an image for qemux86-64. When finishing the build, bitbake spends quite some time in do_image_tar. Is that necessary, when the image is only run in qemu?
<manuel>
I understand qemu accesses the .ext3 file
manuel is now known as manuel1985
<JosefHolzmayr[m]>
manuel: probably not exactly necessary.
manuel1985 is now known as manuel
<JosefHolzmayr[m]>
what do you defined as "quite some time"?
<manuel>
A minute or so
<manuel>
Can I disable it?
<JosefHolzmayr[m]>
IMAGE_FSTYPES = "ext3" in local.conf to try. in the long run you might want to derive your own qemu version as MACHINE and set it there.
koty0f has quit [Quit: Konversation terminated!]
<manuel>
Thanks!
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jmiehe has joined #yocto
Starfoxxes has joined #yocto
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
florian has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
jmiehe has quit [Quit: jmiehe]
<RP>
kergoth: an interesting dilemma: DESCRIPTION_abc = "Refer to ${DESCRIPTION}", OVERRIDES = "abc", getVar("DESCRIPTION")
<RP>
Only "works" today since package.bbclass flattens variable references badly in emit_packagedata and I just tried to fix that
alex88 has quit [Ping timeout: 240 seconds]
alex88_ has joined #yocto
amitk has joined #yocto
<vd>
multiple overrides works, right? FOO_append_a_b is applied if and only if OVERRIDES contains both "a" and "b", correct?
<RP>
vd: yes
* RP
takes a wild guess that changing the way DESCRIPTION and SUMMARY work at M4 would not go down well
leon-anavi has joined #yocto
<ant__>
RP: sigh..like IMAGE_FSTYPE...all is set in a random class...
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
vd has quit [Quit: Client closed]
<ant__>
well, the original sinner was IMAGE_FSTYPES_collie :)
<RP>
fray: I think I found the issue for the user corruption and a fix that hopefully doesn't break too much else
* RP
sends a patch out
<fray>
excellent.. I'll tkae a look
bluearc has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
<RP>
The trouble was the pkgdata was identical for both dynamic and static cases with the recent do_package reproducibility improvements so it matched them up and accelerated the build with it
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
<fray>
Ya,.. I can't say I completely undertand the fix, but I think I get the general idea..
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
Guest53 has quit [Quit: Client closed]
yannd has joined #yocto
otavio has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]