<kp7299[m]>
if in .bb layer in RDEPENDS if we are getting error for python packages only then in which path those python packages are required so that they dont show those errors for python
<kp7299[m]>
this all is for recipe-support packages and presently for curl
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<kp7299[m]>
And as per the previous issue it was having webpage link to runtest.p1 , so the patch were having line to fetch that runtest.p1 thus added that to .bb file , but now getting these errors... https://pastebin.com/Bjx50axz
troth has quit [Ping timeout: 256 seconds]
troth has joined #yocto
<kp7299[m]>
kp7299[m]: but as that issue is few years back old, just wanted to know if there is some update in that runtest.p1 file rburton
Wouter0100 has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
troth has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
Wouter0100 has joined #yocto
amahnui has joined #yocto
kroon has joined #yocto
troth has joined #yocto
selff has joined #yocto
mvlad has joined #yocto
<LetoThe2nd>
yo dudX
sstiller has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
selff has quit [Ping timeout: 252 seconds]
selff has joined #yocto
rfuentess has joined #yocto
sstiller has quit [Read error: Connection reset by peer]
mckoan|away is now known as mckoan
<mckoan>
good morning
selff has quit [Quit: Client closed]
selff has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<amahnui[m]>
Good morning
<selff>
morning
<qschulz>
vvn: bmaptool works with bmap files too, so you just need to download both the original file and the bmap one
<RP>
morning
<RP>
qschulz: I don't suppose you'd have some time to look at the migration/release notes patches from paul? I just pushed to master-next. The release is about ready to go apart from these
* RP
doesn't know whether to wait for michaelo next week or not :/
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
dev1990 has joined #yocto
selff has quit [Ping timeout: 252 seconds]
selff has joined #yocto
troth has quit [Ping timeout: 240 seconds]
troth has joined #yocto
bps has joined #yocto
florian has joined #yocto
GNUmoon has quit [Remote host closed the connection]
<kp7299[m]>
Hi RP, qschultz , Could you pls help me out with both issues which I'm facing or what could be possibilities of both
<qschulz>
kp7299[m]: I don't understand your question. I assume HEAD~ fails because you don't have more than one commit in your git repo, but this makes little sense except if you created a local git repo for your change and committed there
<kp7299[m]>
then what about file , do i need to mention file path there in my main repo
<kp7299[m]>
of*
<qschulz>
kp7299[m]: create a commit in openembedded-core git repo
<qschulz>
then git format-patch of that commit
<svuorela>
is kirkstone still expected this month ?
<jclsn[m]>
Nooo, kas doesn't use the .netrc
<jclsn[m]>
Why?
<jclsn[m]>
qschulz: ?
ptsneves has joined #yocto
<jclsn[m]>
I am using kas without docker, so no idea why I would need to bind it manually
<qschulz>
jclsn[m]: I use kas, I do not develop kas nor am I employed by siemens. If something does not work for you, it's a FOSS project, just contribute to it
<qschulz>
or add the correct config options, I don't know
<jclsn[m]>
qschulz: okay okay
<jclsn[m]>
I will write Jan Kiszka
<qschulz>
there'll never be a default configruation that'll suit everybody
<jclsn[m]>
Wonder why he isn't here anyway
<jclsn[m]>
Yeah but .netrc is quite common tbh
<qschulz>
just open an issue on github or spend time contributing code or documentation please
<rburton>
kas doesn't do any fetching itself though, it just tells git to fetch, and git uses netrc
<rburton>
so what's the actual problem?
<jclsn[m]>
rburton: I have files from Artifactory. All the PREMIRRORS problems are fixed now. Turns out I needed to have a .netrc to let wget know about the credentials
<jclsn[m]>
I tested everything with Pyrex, where I have manually bound the .netrc, but I can also just use wget in the terminal to GET stuff from Artifactory
<jclsn[m]>
Only in Kas this doesn't work
<jclsn[m]>
Which is a problem because my CI Pipeline uses kas
<jclsn[m]>
There is nothing regarding this in the documentation unfortunately
<jclsn[m]>
kas' documentation that is
<jclsn[m]>
Works when I use oe-init-environment too, so definitely a kas issue
<ptsneves>
Hey. It used to be that the DEPENDS var was read in base.bbclass and was a deptask for do_configure. Did this change or i am confusing things?
<jclsn[m]>
Oh I think with kas you have the use KAS_PREMIRRORS. Will see if that makes a difference
<ptsneves>
like do_configure[depends] = "D1:do_prepare_recipe_sysroot"
<jclsn[m]>
Another things that is weird is that bitbake-getvar is not working for me atm
<qschulz>
jclsn[m]: if you don't give us more info, we'll never be able to help
<qschulz>
although this is about kas and we're merely users here
<qschulz>
so going through the proper channels for bug reporting would be better
<Saur[m]>
RP: I have read through Paul's migration/release notes and sent a couple of comments to the mailing list.
<qschulz>
Saur[m]: thx, will have a look too. Though I haven't exactly followed the new features/fix for kirkstone so it'll be cosmetic/syntactic comments
<jclsn[m]>
qschulz: Well bitbake-getvar is not there, although the bitbake environment is sourced
<jclsn[m]>
I don't know how to give you more info on this
<jclsn[m]>
For the kas matter I have written an email to their mailing list
<qschulz>
jclsn[m]: well, this is already more info than "bitbake-getvar is not working"
<jclsn[m]>
True
<RP>
Saur[m]: thanks! I'll see if I can tweak the patches as I know Paul might be away for a few days
mckoan is now known as mckoan|away
goliath has joined #yocto
pgowda_ has joined #yocto
<rburton>
ptsneves: that’s what DEPENDS is, yes
<ptsneves>
and if the do_configure[noexec] = "1" is set will the dependencies still be populated?
ardo has quit [Ping timeout: 246 seconds]
<qschulz>
RP: went quickly through paul's patches for the 4.0 release docs
<selff>
i did perf proofiling test for rpi4(raspbian) and rpi4(yocto). There was a big difference in the results on the cpu,thread side.
ardo has joined #yocto
<ptsneves>
did you find the symbol on which there was a big difference?
<selff>
çeviri
<selff>
wrong message
<ptsneves>
congrats by the way
<selff>
btw , i wrote a code in C++ that only does math on an empty main. i kept a timer before entering the loop and at the end of the loop. on raspbian it was completed in 20 seconds, on yocto it took 55 seconds.
<selff>
there was a huge difference in avg per-thread latency, wokeup 4 of 4 threads , 4 threads, each operating on 1024 [private] futexes for 10 secs tests. if you want, i can share the test results with pastebin.
<selff>
çeiri
<selff>
i think i tested the performance of single thread in the code i wrote.
<selff>
the frequencies look the same on paper.
<selff>
ptsneves think you deserve the compliment. it was your and rburton idea
<selff>
I did not do anything :)
<ptsneves>
I think this is a bit outside yocto but i am curious of your problem. Can you share the code and perf logs?
<ptsneves>
perhaps we talk in private to not spam the channel
<selff>
okay, im zipping and sharing the test results and code.
<ptsneves>
ok please paste. I will go for lunch
<selff>
i uploaded it from file.io. if there is another place you want me to upload, i can do it from there.
<qschulz>
(just to know if I send a patch for it or if the buildocs gets updated :) )
<qschulz>
(I anyway need to send a patch ,either to fix/mitigate it or update the min sphinx version)
<RP>
qschulz: I haven't tried to see what breaks with that
<RP>
qschulz, Saur[m]: thanks for the review, I've updated master-next with the tweaks and posted any of the bigger changes
* RP
wonders if this is good enough to merge
<qschulz>
RP: yeah, let's do this change after the release so we don't put more on your plate :)
<RP>
qschulz: I don't think I can take many more problems :/
<jclsn[m]>
Seems like kas builds with its own user and therefore doesn't have access to the .netrc
<jclsn[m]>
I am using oe-init-build-env as a workaround for my pipelines now. Don't think that this will be changed any time soon
<qschulz>
RP: need to send a patch for kirkstone+master to fix this thing
<qschulz>
otherwise we need to have one more patch in yocto-autobuiler-herlper
<qschulz>
are you looking at the EXTRA_USERS_PARAMS yet or should I check what I can do?
<RP>
qschulz: I have not looked at that one so please :)
<rburton>
jclsn[m]: kas container, i presume
<rburton>
as kas on its own doesn't change user
<RP>
qschulz: a patch to about the sphinx 4.0 issue would be useful please. I'm sure we will update eventually but not now
<jclsn[m]>
rburton: I don't use the kas container
<Saur[m]>
RP: Hmm, I don't see any changes to Paul's original patches on master-next?
<selff>
rburton did you see what i wrote? do you have any idea if you have seen it?
<RP>
Saur[m]: I only updated the docs repo, one second and I can update poky
<jclsn[m]>
The ~/.netrc is in my home directory. I guess kas is binding the ~/.ssh directory, but not that file
<RP>
Saur[m]: pushed
<rburton>
jclsn[m]: kas without a container doesn't do anything like that
<rburton>
selff: haven't looked, have never used opencv and my rpi is still in a box, so you'll have to ask someone with experience with those pieces, or dig yourself. a smaller test case is good.
<jclsn[m]>
RP: Well in that case something funky is going on here. As soon as I use Pyrex or the oe-init-build-env instead of the kas build command everything works
<Saur[m]>
RP: Looks good to me, with a caveat that I do not know how the example for QA_EMPTY_DIRS_RECOMMENDATION will look once it is rendered.
<Saur[m]>
I.e., will it look like example code.
<qschulz>
RP: patch for sphinx <4.0 sent
<qschulz>
RP: i'll let you cherry-pick for kirkstone I guess?
<RP>
qschulz: I think the changes will just go to both branches, thanks!
dev1990 has quit [Quit: Konversation terminated!]
<RP>
Saur[m]: I think I put the right sphinx magic in there
<ctxnop>
Hello all, I have a question about making a multiple package recipe. I have a repository that builds 3 kernel modules, out of tree. I think I got this part correctly. But the very same repository provides also 3 command line tools. I want to have a package for every single one. And finally, I want a last package that ship headers to go inside the
<ctxnop>
SDK. I wrote a "do_compile:append" to add the extra compilation steps for the said tools, and a "do_install:append" to install those where I want. Finally I added the differents files to FILES:${PN}-tool-X variables.
<qschulz>
ctxnop: did you add some entries to PACKAGES variable too?
<ctxnop>
It all compiles correctly, the tools packages aren't generated, what am I missing? and I also wonder how I can refer to those separately, like I want tool-A on an image, but tool-B on another image?
<ctxnop>
qschulz yes I did
<qschulz>
ctxnop: IMAGE_INSTALL += "tool-A" on one image, IMAGE_INSTALL += "tool-B" on the other
<qschulz>
honestly, what I would do is have two recipes
<qschulz>
one for the kernel moduels which inherit module class
<qschulz>
and the other for the tools
<qschulz>
clean separation, maybe less hackish too
<qschulz>
at the cost of twice the fetching of sources
<ctxnop>
qschulz I'll check again for the IMAGE_INSTALL cause I remember that I did that for another package and did not worked, ended up in adding all in all images as it wasn't that important. But I surely missed something, so I'll check again
<qschulz>
ctxnop: check the RDEPENDS of your packages so they don't pull in too many packages they don't need
<ctxnop>
qschulz Yeah I was think of making two recipe as well but I really dislike the idea it has the same SRC_URI because it mean that the two can get out of sync (one recipe pointing to a different commit than the other)
<qschulz>
ctxnop: use a .inc included by both recipes
mgrseins has joined #yocto
<ctxnop>
qschulz Ohh silly of me... I just didn't think about a .inc file -_-
mgrseins has left #yocto [#yocto]
arkados has joined #yocto
arkados has left #yocto [#yocto]
<ctxnop>
just checked out my PACKAGES variable and it is as expected listing the extra tools
<qschulz>
ctxnop: then I think you might have an issue with the ordering of your packages in PACKAGES
<qschulz>
and/or FILES filters of other packages being too wide
<ctxnop>
the extra tools are the lasts in PACKAGES
kroon has quit [Quit: Leaving]
<qschulz>
ctxnop: oe-pkgdata-util find-path '*file*' should help you see if your file makes it somewhere at least
<qschulz>
ctxnop: the PACKAGES is read from left to right
<qschulz>
whatever matches the FILES filter of the package currently being populated will be in that package only
<qschulz>
so it is possible (and likely) another package took your files in
<ctxnop>
oe-pkgdata-util says that no packages are producing the extra tool I tried
<qschulz>
ctxnop: mmm not great, then I guess you need to check that your do_install actually works
<qschulz>
check inside ${WORKDIR}/image that your file is ther
<qschulz>
e
<ctxnop>
yes, that is my conslusion also
<qschulz>
ctxnop: you can also check what's the content of the do_install task in ${WORKDIR}/temp/{log,run}.do_install
<ctxnop>
(I'm sorry to be a bit slow, I'm forced to work remotely today, so accessing anything takes times ...-_- )
arkados has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<arkados>
hello EXTRA_USERS_PARAMS can be used only local.conf not in a receipe ? in a receipe I must inherit user_add ?
<ctxnop>
so, indeed, none of my extra files are in $WORKDIR/image, I'll will investigate on that, thanks a lot for your help qschulz
<qschulz>
ctxnop: gives me time to work on other stuff too, so it's alright don't worry :)
<qschulz>
ctxnop: ahah! so an issue with do_install:append indeed. Are you sure you are on a yocto release that supports :append override syntax?
<qschulz>
(it used to be _append before)
<ctxnop>
Yes I'm sure of that, I'm on honister, waiting to go on kirkstone as soon as it's released
<ctxnop>
I also have to maintain an older image based on dungell so I'm used to this particular issue :p
<RP>
qschulz: I think that top level doc version issue might now be working?
<qschulz>
ctxnop: update to latest dunfell and th newer syntax is supported too
* RP
didn't touch it
<qschulz>
RP: ah yes
<qschulz>
oh...
<qschulz>
was this a local cache issue?
nemik has quit [Ping timeout: 246 seconds]
<RP>
qschulz: don't know
<qschulz>
because I had to Ctrl+Shift+R to see it
<qschulz>
because it was still incorrect
<qschulz>
so probably cache indeed
<qschulz>
happy it's fixed :)
<arkados>
qschulz, when i made it a receipe mysuers.bb inherted from extrausers bitbake compile the receipe but produce an error when I IMAGE_INSTALL:append " myasers"
<arkados>
:q
<rburton>
what was the error? hard to comment otherwise.
<arkados>
User-Agent: falling back to 'libdnf': could not detect OS or basearch
nemik has joined #yocto
<rburton>
that's not an error
<arkados>
I didn't add do_install in the receipe .. Do I have to do ?
selff has quit [Quit: Client closed]
<arkados>
Error: Unable to find a match: myusers
xmn has joined #yocto
<arkados>
but bitbake-layers show-receipes show myusers
<rburton>
the package probab;y didn't generate as it was empty
<rburton>
set ALLOW_EMPTY to generate an empty package which creates a user (see the docs)
<amahnui[m]>
Hello, I ran the `runqemu qemux86_64` a few days ago and was meaning to say that my mouse is not functioning on QEMU, I wish to ask if it is normal and if there is a way to make it work.
<rburton>
arkados: oh, extrausers is an *image* class
<ptsneves>
i work with them and they update frequently.
<ptsneves>
They have their weird conventions and their own kernel recipes. If you can live with that then that is it.
<ptsneves>
Also what do you look for in the SoC?
<qschulz>
GhastlySnowflake: also, SoC OEM highly depends on what you mean by that. Do you mean SoC vendor (i,e, are you doing your own hardware based on an SoC?), a SoM vendor (basing your hardware on a System on Module, like Toradex for example)
<qschulz>
GhastlySnowflake: also, what do you mean by BSP? Yocto layers? Decently recent U-Boot, Linux kernel, etc... ?
<qschulz>
combination of that?
selff has joined #yocto
dmoseley has joined #yocto
<GhastlySnowflake>
qschulz: Good point! I am mostly interested in the SoM. Hopefully I'd like something which is a bit more enterprise supported then the RPi which has a BSP yocto layer. What i mean by BSP - that it's at least on some lts version on the kernel and yocto (don't know if uboot has lts), and one doesn't have to work on low level stuff to get to a booting
<ctxnop>
qschulz Seems that whatever I try my do_install:append is not called. Tried with "do_install_append" but obviously got the error that it's not a supported syntax anymore. Tried to create my own task "do_install_tools" and used "addtask do_install_tools after do_install before do_package", but it then install files using my user instead of 'root' so
<ctxnop>
that do_package fails because of permissions. So I ended up into writing simply 'do_install', which completly override the default, but as the default is only doing a "module_do_install", then I added this in my do_install and now everything works as expected
<qschulz>
ctxnop: mmm, this does not look too good
<qschulz>
ctxnop: is this something you can share publicly?
<qschulz>
so that we can reproduce on our side?
<qschulz>
I'm pretty sure do_install:append should work for recipes inheriting module bbclass
sakoman has joined #yocto
<ctxnop>
unfortunately no, I'm on NDA on all of this stuff :/
<ctxnop>
I'll try to make a reproducible exemple out of dummy sources later if you want
hcg has quit [Quit: Client closed]
<ctxnop>
but as of right now, I think I can live with it, it so much better than the previous way on handling all this stuff
mihai has quit [Quit: Leaving]
<qschulz>
ctxnop: yes, a small example would be plenty enough for us :)
beneth has quit [Read error: Connection reset by peer]
rfuentess has quit [Remote host closed the connection]
NishanthMenon[m] has quit [Quit: You have been kicked for being idle]
ar__ has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 272 seconds]
florian has quit [Quit: Ex-Chat]
<ctxnop>
qschulz Just to let you know, I just tried to reproduce the issue, starting from scratch, using the hello-mod as a starter. As of right now it just works out of the box, so I can't reproduce my issue. It then means that I have something, somewhere, that as a side effect. When I'll have some time I'll chase down the differences to find what cause
<ctxnop>
the bug. If I find something I'll reach you out to let you know.
<qschulz>
ctxnop: good and bad news at the same time :/
<ctxnop>
more bad than good in my opinion, because it means that I may have some other issues that I haven't spotted yet
<qschulz>
(good for us, bad for you :) )
<ctxnop>
yes ^^'
<ctxnop>
As this project will be ported to kirkstone as soon as it's released, it may disappear in the process, so I won't run on this for now
<BignauxRonan[m]>
hi, if i've some COMPATIBLE_HOST = 'xxx" in meta/recipes-core/images/core-image-minimal-initramfs.bb , can i override it in a bbappend in my layer ?
<BignauxRonan[m]>
or it should have ?= to be able to ?
<BignauxRonan[m]>
it uses to "Use the same restriction as initramfs-module-install" but i don't want to use it, i can since INITRAMFS_SCRIPTS has "?=" ...
<qschulz>
BignauxRonan[m]: yes you can in a bbappend
<BignauxRonan[m]>
so i should make it bad
<qschulz>
everything is flattened and read from top to bottom, bbappends content is added after the original recipe
<qschulz>
wait.. COMPATIBLE_HOST???
<qschulz>
I thought it was COMPATIBLE_MACHINE
<qschulz>
why would you need COMPATIBLE_HOST?
<BignauxRonan[m]>
i tryied to had my machine but i need to add mipsel ok
<qschulz>
(well, COMPATIBLE_MACHINE on an image recipe does not make much more sense to me, just highlights there's not enough abtrsaction in your layer and recipes
<BignauxRonan[m]>
for non-native recipe, compatible-host is the target
<BignauxRonan[m]>
seems to work with COMPATIBLE_HOST = 'mipsel-poky-linux'
<qschulz>
BignauxRonan[m]: well, I learned something new today
<qschulz>
still don't understand why you wyuld use a COMPATIBLE_HOST for an image recipe since to me a native image recipe makes very little sense
<qschulz>
if that is even possible
<qschulz>
BignauxRonan[m]: you could also append to it to keep the original value
<BignauxRonan[m]>
yeap, i try to find where i read that in manual
<qschulz>
I assume something like COMPATIBLE_HOST .= "|mipsel-poky-linux" would do
<BignauxRonan[m]>
A regular expression that resolves to one or more hosts (when the recipe is native) or one or more targets (when the recipe is non-native)
<qschulz>
yeah but still, a native image recipe?
<qschulz>
anyways, not important :)
<BignauxRonan[m]>
yeah, it refuses to build if i don't fix that so ...
ptsneves has quit [Ping timeout: 252 seconds]
<qschulz>
BignauxRonan[m]: I was more challenging the use of COMPATIBLE_HOST in an image recipe over COMPATIBLE_MACHINE (and actually... COMPATIBLE_MACHINE itself in a recipe is telling something;s not done according to best practices somewhere :) )
<BignauxRonan[m]>
ah yes but that's not my business, i can't contribute yocto when i don't have something working here :D
<BignauxRonan[m]>
but yes, i don't think it should have inherited COMPATIBLE_HOST here since we can use this recipe without initramfs-module-install
troth has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
ctxnop has quit [Quit: Client closed]
troth has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
amahnui has quit [Quit: Connection closed for inactivity]
florian_kc has joined #yocto
tgamblin has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 276 seconds]
dtometzki has quit [Read error: Connection reset by peer]
<khem>
RP: we need to replicate create_merged_usr_symlinks() for recipe specific sysroot too
florian_kc has joined #yocto
PaowZ has quit [Ping timeout: 240 seconds]
PaowZ has joined #yocto
dtometzki has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
dti has joined #yocto
sakoman has quit [Quit: Leaving.]
<janvermaete[m]>
hi,
<janvermaete[m]>
To start with ptest for my own recipes, what's the best example to look at?
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
amahnui has joined #yocto
bluelightning has quit [Quit: Konversation terminated!!!111]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<kergoth>
khem: Do you run sstate-diff-machine in CI/autobuilder, and if so, how do you go about doing that in a clean way? I'd like to make sure things that we expect to be shared between some of our configurations are, and would like to know which pieces are not, across our build matrix.
<kergoth>
khem: ah, okay, so comparing a specific subset of machines. thanks
<kergoth>
khem: I'm looking at using more generic arm tuning, the way it was done by angstrom and others, and I want to *know* the toolchain and its runtime isn't being pointlessly rebuilt across similar machines, sstate-diff-machines is probably the best bet, yeah?
<khem>
yeah it is
<kergoth>
When using an external toolchain, we usually have a specific list of supported configurations, often somewhat generic, and the build maps the machine to the most specific compatible external configuration. If I then move to internal builds, I want to make sure across the matrix of machines that we don't build more configurations than the external would have had, if that makes sense. Reduces the need for increased test coverage
<kergoth>
between the two
<kergoth>
looking for equivalence between the two. sstate-diff-machines looks perfect, but haven't played with it much. time to do so!
<khem>
yeah its doable, but I think you have to bridge the gaps between defined configurations first between external and internal, since that is critical, internal can have many variations
<kergoth>
Hmm yeah, that's true. Right now we only support glibc, so that helps, but I might need to add warnings to our distro if the user is building an unsupported toolchain configuration or something
<kergoth>
must be nice doing builds in a tmpfs :)
<khem>
heh the tmpfs is on 15year old RAM, SSDs of today are faster than that
PaowZ has quit [Ping timeout: 250 seconds]
PaowZ has joined #yocto
florian_kc has quit [Ping timeout: 272 seconds]
ardo has joined #yocto
sakoman has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
mvlad has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 240 seconds]
PaowZ has quit [Remote host closed the connection]
PaowZ has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
goliath has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
mickeypash has joined #yocto
PaowZ has quit [Remote host closed the connection]
mickeypash has quit [Quit: Client closed]
geoff_ has quit [Ping timeout: 246 seconds]
amahnui has quit [Quit: Connection closed for inactivity]