Monday, 2021-03-29

*** zkrx <zkrx!> has quit IRC00:10
*** Spooster <Spooster!> has quit IRC00:25
*** zkrx <zkrx!> has joined #yocto00:25
*** Spooster <Spooster!> has joined #yocto00:33
*** Spooster <Spooster!> has quit IRC00:35
*** Spooster <Spooster!> has joined #yocto00:36
*** sakoman <sakoman!~steve@> has quit IRC01:08
*** bzb <bzb!> has quit IRC01:09
*** dreyna_ <dreyna_!> has quit IRC01:15
*** [Sno] <[Sno]!> has joined #yocto01:19
*** sno <sno!> has quit IRC01:21
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:3d86:e11:ab6d:9d24> has joined #yocto01:24
*** yizhao <yizhao!~zhaoyi@> has quit IRC01:24
*** Spooster <Spooster!> has quit IRC01:25
*** Spooster <Spooster!> has joined #yocto01:26
*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:26
*** itseris <itseris!> has joined #yocto01:30
*** Spooster <Spooster!> has quit IRC01:31
*** itseris <itseris!> has joined #yocto01:31
* paulg wonders who'd complain if we declared xxd-native a part of ASSUME_PROVIDED...01:56
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:59
*** fl0v0 <fl0v0!~fvo@> has quit IRC02:30
*** fl0v01 <fl0v01!~fvo@> has joined #yocto02:30
*** yizhao <yizhao!~zhaoyi@> has quit IRC02:40
*** kaspter <kaspter!~Instantbi@> has quit IRC02:44
*** dreyna_ <dreyna_!~dreyna@2601:646:4201:e280:e8d1:57a4:e041:cb94> has joined #yocto03:06
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto03:21
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:25
*** RP <RP!~RP@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has quit IRC03:35
*** RP <RP!~RP@2001:8b0:aba:5f3c:96de:80ff:fe6d:2d2b> has joined #yocto03:42
*** samvlewis <samvlewis!~samvlewis@> has joined #yocto03:48
*** wooosaiiii <wooosaiiii!> has quit IRC04:01
*** wooosaiiii <wooosaiiii!> has joined #yocto04:02
*** jobroe <jobroe!> has joined #yocto04:05
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto04:22
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:3d86:e11:ab6d:9d24> has quit IRC04:22
*** Spooster <Spooster!> has joined #yocto04:37
*** Spooster <Spooster!> has joined #yocto04:40
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has quit IRC05:07
*** Spooster <Spooster!> has quit IRC05:13
*** Spooster <Spooster!> has joined #yocto05:14
*** Spooster <Spooster!> has quit IRC05:18
*** AndersD <AndersD!> has joined #yocto05:26
*** nslu2-log__ <nslu2-log__!> has quit IRC05:27
*** nslu2-log <nslu2-log!> has quit IRC05:27
*** warthog9 <warthog9!> has quit IRC05:28
*** nslu2-log <nslu2-log!> has joined #yocto05:28
*** nslu2-log_ <nslu2-log_!> has joined #yocto05:28
*** warthog9 <warthog9!> has joined #yocto05:31
*** AndersD_ <AndersD_!> has joined #yocto05:37
*** AndersD <AndersD!> has quit IRC05:39
*** warthog9 <warthog9!> has quit IRC05:40
*** w00die <w00die!~w00die@> has quit IRC05:41
*** w00die <w00die!~w00die@> has joined #yocto05:43
*** warthog9 <warthog9!> has joined #yocto05:45
*** ctlnwr_ <ctlnwr_!> has joined #yocto05:48
*** ctlnwr <ctlnwr!~catalin@> has quit IRC05:52
*** agust <agust!> has joined #yocto05:57
*** B0ned1ger <B0ned1ger!> has joined #yocto05:58
*** dreyna_ <dreyna_!~dreyna@2601:646:4201:e280:e8d1:57a4:e041:cb94> has quit IRC06:04
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto06:05
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has joined #yocto06:08
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:11
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:589e:5d0e:8469:633b> has quit IRC06:12
*** goliath <goliath!> has quit IRC06:32
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:1c6f:f48c:3ebc:63d> has joined #yocto06:33
*** goliath <goliath!> has joined #yocto06:35
*** mckoan|away is now known as mckoan06:38
mckoangood morning06:39
*** yannholo <yannholo!> has joined #yocto07:25
*** Fanfwe <Fanfwe!> has quit IRC07:27
*** Fanfwe <Fanfwe!> has joined #yocto07:27
*** caiortp <caiortp!> has joined #yocto07:33
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:dbe9:fd6c:d1a9:4bb5> has joined #yocto07:41
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:43
*** kyanres <kyanres!> has joined #yocto07:43
*** ENPJ <ENPJ!~ENPJ@> has joined #yocto07:44
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto07:50
*** dev1990 <dev1990!> has joined #yocto07:53
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC08:25
*** kpo <kpo!> has joined #yocto08:26
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto08:30
*** tnovotny <tnovotny!> has joined #yocto08:31
*** oobitots51 <oobitots51!> has joined #yocto08:33
*** kpo <kpo!> has quit IRC08:38
*** kpo <kpo!> has joined #yocto08:38
*** kpo <kpo!> has quit IRC08:45
*** kpo <kpo!> has joined #yocto08:45
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto08:48
*** Bunio_FH <Bunio_FH!> has joined #yocto08:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC09:19
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto09:20
*** Bunio_FH <Bunio_FH!> has quit IRC09:21
*** pankaj347 <pankaj347!7aa678a8@> has joined #yocto09:24
*** Bunio_FH <Bunio_FH!> has joined #yocto09:36
*** eFfeM1 <eFfeM1!> has joined #yocto09:45
*** JosephAntony <JosephAntony!a5e17a71@> has joined #yocto09:46
eFfeM1Hi, anyone an idea what is wrong with the following:09:49
eFfeM1I'm trying to write a recipe for a python package whose source is on github, but I end with a package:09:49
eFfeM1there is no platform specific code in the package. (just py/pyc files)09:49
eFfeM1How do I set the right architecture?09:49
qschulzeFfeM1: what is the right architecture?09:54
eFfeM1qschulz I want to build for arm64 but the .deb ends up in aarch6409:55
eFfeM1but effectively the package is architecture independent09:56
qschulzeFfeM1: aarch64 is the official name of arm6409:57
eFfeM1facepalm; of course :-)09:57
*** B0ned1ger <B0ned1ger!> has quit IRC09:57
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:852:178e:b383:9e8d> has joined #yocto09:58
*** B0ned1ger <B0ned1ger!> has joined #yocto09:58
eFfeM1qschulz I came here because my rootfs complained about mismatches, trying again now to get the actual error message back09:59
qschulzIn the end, I think most python recipes aren't architecture independent from Yocto PoV. I guess because anyway they depend on the Python binary which is architecture dependent so the benefit is extremely minimal. Wild guess though09:59
qschulzruntime depend*09:59
eFfeM1makes sense09:59
qschulzeFfeM1: then let's have a look at this error first :)10:00
eFfeM1qschulz here is the end oof the do_rootfs log:
eFfeM1lots of similar dpgt warnings before that10:05
eFfeM1dpkg: warning: package architecture (arm64) does not match system (amd64)10:05
abelloniaren't they architecture dependent because of the .pyc ?10:07
eFfeM1abelloni yes, actually the architecture dependency is not the problem, it is the issue in install10:09
qschulzabelloni: that would indeed make sense yes. But I'm not sure it is the issue? My guess right now is that the dpkg warnings are ok because dpkg is running on the building machine (amd64) to build the rootfs on the building machine for the target (which is arm64)10:09
abellonieFfeM1: can you share the do_rootfs.log ?10:10
eFfeM1abelloni that is a bit hard as it is on a docker whose host I have to access via ssh, but you and qschulz helped me looking at the right place in the log and I now know what the issue is (but not yet how to fix it)10:12
eFfeM1The issue is that the src git repo actually contains sources for three packages, and do_rootfs fails with10:13
eFfeM1 trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r010:13
eFfeM1whiich si the real cause of my problem10:14
qschulzeFfeM1: do you have multiple recipes for the same src git repo?10:15
eFfeM1basically the packages are in subdirs of the git repo, so I ended up with10:15
eFfeM1qschulz Yes!10:15
abellonibitbake should have complained earlier10:15
eFfeM13 recipes that buiild a python package in 3 different subdirs  of the same git repo10:16
eFfeM1oh and I am a bit of a python n00b; I was just asked to create a recipe for these three packages10:18
eFfeM1they are 3 different pip packages that in the end I want to get into my image10:18
eFfeM1I also tried a do_install() with body pip3 install bosdyn-mission etc but then of course it all ended up in sysroot-native or so, so that did not fly10:20
eFfeM1qschulz would it help if I carve one recipe that does three python3 calls  in do_compile and do_install ?10:22
rburtonwhy not just have three recipes that use the same SRC_URI10:24
rburtonas they're separate packages10:24
rburtonyou *can* do what you want10:25
eFfeM1rburton that is what I have now and that gives me10:25
eFfeM1 trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r010:25
eFfeM1when adding all three packages to my image10:25
rburtonso presumably pip installing the 'top level' one is installing the others for you10:25
rburtonsounds like you don't really need multiple10:26
rburtonhow i'd approach the 'multiple packages in a repo' thing is a custom do_compile that sets DISTUTILS_SETUP_PATH to $S/packageone then calls distutils3_do_compile, then DISTUTILS_SETUP_PATH=$S/packagetwo; distutils3_do_compile, etc10:27
rburtonthat will run setup in each directory.  ditto for install.10:27
rburtonbut if there's a "top level" module that depends on the others, just install that and it looks like the dependencies are being handled for you10:27
eFfeM1yeah I was considering your multiple packages approach, I'll also peek at the dependencies. Will be after lunch though as it is now noon here, back in 30mins10:29
*** zbodek <zbodek!> has joined #yocto10:30
*** BimBam <BimBam!531fc3b6@> has joined #yocto10:30
*** BimBamBim <BimBamBim!531fc3b6@> has joined #yocto10:34
zbodekhey. I have a question. In the bb recipe I created I include a .inc file from another recipe in another layer. Everything would work but the .inc file pulls a patch in SRC_URI and of course unless I have a local "files" with that patch, it won't be found.10:36
zbodekIs there a way to do it "right" ?10:36
BimBamBimHello, Im experiencing weird problem with my yocto and cant handle that alone, maybe someone here has experienced that.10:38
BimBamBimI got my new build machine and it works fast etc,  BUT, for few packages the build stalls. I mean - they keep rolling forever (now its over 5000s and cpu usage is almost 0% on all cores). I made some investination and I found out that for 4 out of 6 of there packages the build blocks on:10:38
BimBamBimif [ -p <MY_PATH>/build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtquickcontrols/5.9.7+gitAUTOINC+1afae24d7f-r0/temp/fifo.3554347 ] ; then10:38
BimBamBimDo you have any ideas what could cause that ? I didnt touch this recipe and this build works wello n 4 other machines10:38
*** eFfeM1 <eFfeM1!> has quit IRC10:41
*** kyanres <kyanres!> has quit IRC10:41
*** vitali <vitali!~vitali@> has quit IRC11:03
*** richbridger <richbridger!> has quit IRC11:03
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:04
*** vitali <vitali!~vitali@> has joined #yocto11:05
*** eFfeM1 <eFfeM1!> has joined #yocto11:06
*** vitali <vitali!~vitali@> has quit IRC11:07
eFfeM1zbodek you could consider adding a FILESEXTRAPATHS_prepend or so to your recipe11:08
*** vitali <vitali!~vitali@> has joined #yocto11:11
*** BimBamBim <BimBamBim!531fc3b6@> has quit IRC11:15
kanavinkhem, can you look at please?11:16
zbodekeFfeM1: I could but then it would need to be an absolute path wouldn't it?11:18
zbodekeFfeM1: and the "files" directory is in another layer11:18
eFfeM1I suspect the layering is not a problem, the fact that it is a different package could be.11:20
eFfeM1If what you want to do is to create a  recipe for a different version best keep the directory structure the same (so the same folder in your layer)11:20
eFfeM1if you have a different recipe thaen consider if youu want to include an inc file from a different package11:21
eFfeM1and if you want a quuick and dirty solution copy over whatever you need; this is basically what I did when I had to go for an older version of python11:22
zbodekeFfeM1: copying of the files directory to have same structure works fine but I am afraid it won't be acceptable11:26
zbodekI'm trying to add a sample application to my layer, that will use this layer+recipe
zbodekmy recipe will look similar to this one
zbodekwith an exception that the source code will be pulled from somewhere else. still I'm including which will pull the patch from meta-zephyr files via SRC_URI11:28
zbodekquite weird usage of meta-zephyr layer but I don't know how to attack it differently11:29
*** BimBamBim <BimBamBim!531fc3b6@> has joined #yocto11:29
BimBamBimIm sorry I got disconnected, if someone replied to my question please repeat11:30
*** ENPJ <ENPJ!~ENPJ@> has quit IRC11:31
*** leon-anavi <leon-anavi!~Leon@> has quit IRC11:31
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:35
*** JosephAntony <JosephAntony!a5e17a71@> has quit IRC11:36
qschulzzbodek: I think you could probably setup a PREMIRRORS in your local.conf to redirect the SRC_URI request to one of your "somewhere else" repo?11:38
qschulzzbodek: but indeed, FILESEXTRAPATHS does nto seem to be an appropriate mechanism since you need to know where the layer with the .inc file is located ont he FS and it's not guaranteed to be stable over time11:39
eFfeM1qschulz do you by any chance have a suggestion or pointer on how to build 3 packages from the same git repo. I'm also good if it just generates one yocto package, but being a python n00b I do not really know how to tackle this11:42
*** ENPJ <ENPJ!~ENPJ@> has joined #yocto11:43
eFfeM1actually the way I build now each package gets an at top level but they are identical11:44
qschulzeFfeM1: rburton suggested something, have you tried that already?11:59
rburtonif they're writing the same file then you'll need to understand any dependencies and sort out the packaging12:03
rburtonas you're not showing us the source, it's hard to help12:04
*** ahalaney <ahalaney!~ahalaney@> has joined #yocto12:06
*** sagner <sagner!~ags@2a02:169:3df5::4db> has joined #yocto12:08
eFfeM1rburton I have this:12:08
eFfeM1do_compile() {12:09
eFfeM1        DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-client; distutils3_do_compile12:09
eFfeM1        DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-choreography-client; distutils3_do_compile12:09
eFfeM1        DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-mission; distutils3_do_compile12:09
eFfeM1oops, I see something12:09
eFfeM1the git part should not be there as it is part of #{S}; hovever without it, it also tries to find in ${S}12:11
eFfeM1I also tried without the ;  but saem result12:11
eFfeM1...python3-bosdyn-sdk/2.3.3-r0/git//': [Errno 2] No such file or directory12:11
rburtonwhy dont' you just do separate recipes for client, mission and choroegograph, and let -core ship the top-level bosdyn/__init__12:13
rburton(deleting it from the other recipes)12:13
eFfeM1rburton that seems the simplest solution, I have the 3 recipes already but need to see how to best get rid of the __init__py file in the other recipes12:14
rburtondo_install_append() { rm ${D}/${libdir}/python*/bosdyn/}12:15
zbodekeFfeM1: It seems my problem can be resolved by adding FILESEXTRAPATHS_prepend := "${THISDIR}/files:" to the inc file that pulls the patch. thank's for your help anyway12:15
eFfeM1rburton guess I need to make sure that the one with the is installed last12:16
eFfeM1zbodek you're welcome, glad to be of help12:17
*** zbodek <zbodek!> has quit IRC12:18
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:212b:99c:9e11:bd49> has joined #yocto12:28
eFfeM1rburton the rm is a good plan, your snippet was missing the site-packages part in the path but that was easy to fix, now still seeing how to get them installed in the right order as indeed the one with the __init__ must be last; but they are not processed in the order as they appear in IMAGE_INSTALL, seems they are sorted12:34
eFfeM1I'm now trying to have the recipe with the __init__ to have an RDEPENDS on the other two12:34
eFfeM1that does not work either, as they are sorted I either need to get rid of the in the package, for now I am considering just to stuff the file in the dbg package or so12:39
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:dbe9:fd6c:d1a9:4bb5> has quit IRC12:43
*** Yumasi <Yumasi!> has joined #yocto12:44
eFfeM1rburton in the end I did this in two packages and that solved the issue:12:46
eFfeM1FILES_${PN}-dbg += "${libdir}/python*/site-packages/bosdyn/"12:47
eFfeM1will probably make it a separate package12:47
eFfeM1anyyway I now can proceed.12:47
eFfeM1rburton qschulz abelloni thanks for your help!12:48
*** oberstet <oberstet!~oberstet@> has quit IRC12:51
*** Spooster <Spooster!> has joined #yocto12:53
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:212b:99c:9e11:bd49> has quit IRC12:59
*** Spooster <Spooster!> has quit IRC13:01
*** Spooster_ <Spooster_!> has joined #yocto13:01
rburtoneFfeM1: why do they need to be installed in a particular order? just  putting the init in the -dbg package is *horrible*13:03
*** eFfeM1 <eFfeM1!> has quit IRC13:03
*** eFfeM1 <eFfeM1!> has joined #yocto13:05
*** aganders3 <aganders3!> has joined #yocto13:10
aganders3Hi all - I'm a Yocto newbie and just have my first build (Gatesgarth core-image-minimal) running on my target hardware (intel x86-64). For the next step, I'd like to add Nvidia GPU drivers, but I have not found much information. This seems like it would be a relatively common use-case, so I'm curious if I have the wrong idea here.13:23
aganders3 I found an old mailing list thread about this but it seemed to die off without resolution:
*** oberstet <oberstet!~oberstet@> has joined #yocto13:38
*** tnovotny <tnovotny!> has quit IRC13:40
*** tnovotny <tnovotny!> has joined #yocto13:43
*** emrius <emrius!> has joined #yocto13:51
qschulzaganders3: you probably need the nouveau kernel driver to be compiled by the kernel recipe either built in or as a module and have mesa packages installed13:51
qschulzmaybe some additional X packages too13:52
aganders3qschulz: thanks! Unfortunately my primary use (headless system) is CUDA, which I don't think the nouveau driver supports.13:52
*** kaspter <kaspter!~Instantbi@> has quit IRC13:53
aganders3I noticed there is a gentoo ebuild for these drivers (, maybe that would be a good starting point for creating a bitbake recipe?13:54
qschulzaganders3: is there a reason for going with Yocto for this build and not, e.g. gentoo or other distros?13:57
*** ENPJ <ENPJ!~ENPJ@> has quit IRC13:59
aganders3Maybe it's the wrong direction. We're using Ubuntu now and having trouble managing updates in the field (kind of an IoT-like setup). I've been looking at projects like RAUC and SWupdate to enable atomic updates, and that led me to looking into Yocto.14:00
aganders3We're in kind of a weird space I feel where we have a headless system with basically desktop-class hardware, but we want to treat it a lot like an embedded system.14:00
*** sakoman <sakoman!~steve@> has joined #yocto14:01
*** sgw1 <sgw1!~sgw@2601:642:c400:ecf0:a579:bb0e:c0d7:fe81> has quit IRC14:08
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC14:11
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto14:17
*** ssajal <ssajal!> has joined #yocto14:18
*** Lihis <Lihis!> has quit IRC14:19
emriusHey folks, could you help me out on this one?14:20
emriusI'm trying to set the `APPEND` variable to set `isolcpus=2` for the kernel cmdline.14:20
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has joined #yocto14:20
emriusI just added a dedicated machine config named `raspberrypi4-custom.conf` within which I then added `APPEND...` and override MACHINE back to `raspberrypi4` to not break any other dependencies14:21
emriusStill, my `/proc/cmdline` does not include the `isolcpus` statement. I'm a bit puzzled how to do that14:22
qschulzemrius: kernel parameters are set via a config.txt file on the boot partition on RPi IIRC14:22
emriusI thought that was just one out of several options? Do I *have* to do that via conig.txt on RPis?14:23
qschulzemrius: bootloader is board specific. RPi has its own weird bootloader. By default, this weird bootloader is used and it uses config.txt (at least in *MANY* distros, don't remember for Yocto).14:26
emriusqschulz: Okay, thanks. But also are you sure about `config.txt`? I tried that on an already bitbaked image and it doesn't work either. Or does the flag have to be present at compile time?14:27
qschulzemrius: otherwise, you have bootargs in U-Boot if it's used, but needs to be put into U-Boot environment which can be done in several ways14:28
qschulzemrius: config.txt is a txt file, so no, no need for it to be done at compile time if you just want to play with it14:28
emriusqschulz: Okay, then it doesnt work through config.txt. Or works through `/uboot/cmdline.txt` though. But, I felt that the `APPEND` variable was just so much more convenient. (If it worked)14:29
emrius... and I'm still a bit puzzled. I mean technically that sounds like the right approach right? cf C.1.6. at the veeeeery bottom here
*** eFfeM1 <eFfeM1!> has quit IRC14:34
*** sgw1 <sgw1!~sgw@2601:642:c400:ecf0:3dcc:7a70:d6f3:cfc6> has joined #yocto14:36
*** dreyna <dreyna!> has joined #yocto14:41
qschulzemrius: it appears nowhere in poky thud (2.6), so it was maybe removed and forgotten in the docs?14:43
qschulzemrius: oh geez14:43
emriusqschulz: ah hm... maybe. Tried to tackle that with grep but didn't really come to a conclusion.14:44
emriusWell, then I'm happy that I could contribute to keeping the documentation up to date :)14:45
emriusWhen can I patch the docs?14:45
*** thaytan <thaytan!> has quit IRC14:46
qschulzit is OLD14:49
qschulzemrius: for 2.5, check if there's someone willing to take patches but I would say you won't get approval14:50
qschulzemrius: otherwise:
emriusqschulz: Ok thanks14:51
qschulzI would say it makes sense to remove it since I don't think there's any way to formulate it well enough to list all possible cases14:52
*** thaytan <thaytan!> has joined #yocto14:53
*** Lihis_ <Lihis_!> has joined #yocto14:53
*** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has quit IRC14:54
*** Lihis_ is now known as Lihis14:54
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:57
*** B0ned1ger <B0ned1ger!> has quit IRC14:58
*** B0ned1ger <B0ned1ger!> has joined #yocto14:58
*** kiwi_29 <kiwi_29!> has joined #yocto15:00
*** gsalazar <gsalazar!> has joined #yocto15:04
*** diego_r <diego_r!> has joined #yocto15:05
*** kiwi_29 <kiwi_29!> has quit IRC15:06
*** B0ned1ger <B0ned1ger!> has quit IRC15:13
*** pankaj347 <pankaj347!7aa678a8@> has quit IRC15:14
alex88Is there a way to get the output uboot env variables generated by yocto (without running u-boot since we don't get any output)?15:16
*** ctlnwr__ <ctlnwr__!~catalin@> has joined #yocto15:19
*** ctlnwr_ <ctlnwr_!> has quit IRC15:21
qschulzalex88: a few env variables are actually set at runtime by U-Boot itself so it wouldn't be complete anyway15:22
alex88qschulz, ok so it's better to rely on UBOOT_* checked with bitbake -e?15:26
qschulzalex88: which u-boot env variables are you talking about?15:27
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto15:28
alex88qschulz, basically we have a device that doesn't show anything in the serial console (while with the original SD card from the manufacturer it does) so I'm just trying to compare the u-boot configuration (somehow) to see what can be wrong15:29
alex88I've been told the dtb might be wrong but the dtb is in the rootfs partition so it should be something that's used after u-boot loaded right?15:30
qschulzalex88: there's dtb support in U-Boot too and U-Boot has its own dtb, separate from the kernel;s15:31
*** ctlnwr__ <ctlnwr__!~catalin@> has quit IRC15:31
alex88qschulz, oh ok, because right know what I've done is, took the dtb from the manufacturer SD card, converted to dts with dtc, added it to the kernel using a custom recipe by modifying SRC_URI and setting KERNEL_DEVICETREE to the custom dtb name and that correctly outputs the dtb in the deploy dir15:33
qschulzalex88: the u-boot environment will be for sure accessible at runtime but since I guess you have nothing on serial, it won't help much. If it;s a configuration issue, menuconfig and include/configs/yourboard.h as well as board/<vendor>/<board>/*.c would help you figure out things probably15:33
alex88so this only adds the dtb to the kernel and not u-boot?15:34
qschulzalex88: yeah no, they are different device trees, with potentially different properties/syntaxes/nodes, etc...15:34
qschulzalex88: don't recompile a decompiled dtb, just put the dtb as is in the install step15:34
alex88oh ok, so the dtb I took in rootfs/boot is only for the kernel, I should get the one used in u-boot which without manufacturer support will be hard I imagine15:35
alex88oh ok will do that15:35
qschulzalex88: some old U-Boot don't have dtb support15:35
qschulzI mean, for configuring itself15:35
alex88the one they use is 2014.07 and it contains a fdtfile variable that points to the device dtb filename
*** AndersD__ <AndersD__!> has joined #yocto15:38
qschulzalex88: you're in for a treat with such an old u-boot :)15:38
*** AndersD__ <AndersD__!> has quit IRC15:38
alex88qschulz, at least that one is working :)15:39
*** AndersD_ <AndersD_!> has quit IRC15:39
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:cead:852:178e:b383:9e8d> has quit IRC15:40
qschulzalex88: the file you send very much looks like a file used to setup the environment and you also have uEnv.txt support probably seeing it being mentioned15:40
alex88the sd card they provide doesn't contain uEnv.txt, that file is the output of the printenv command run from u-boot15:41
alex88so, without a dtb for u-boot, is it hard to achieve a working u-boot? we're also considering getting a consultant do it but since we're doing this as a favor for a customer that has hundreds of these useless devices we can't invest week of development, we will rather have the customer buy another hardware with an available bsp layer15:43
paulgWARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400'15:43
qschulzalex88: what exactly are you trying to achieve?15:43
paulggetting a bunch of them in what is probably about a month old(ish?) build directory.15:44
qschulzalex88: since it seems you have a working U-Boot from your vendor and don't have much time to spend :)15:48
qschulzalex88: anyway, you might receive more help on #u-boot IRC channel, but porting your board support to a new U-Boot is probably not a one week thing15:49
alex88qschulz, get a minimal image (created via yocto) to boot on the device..  yes we have the working u-boot from the vendor. I've also tried to just replace the rootfs but it hangs on "starting kernel"15:49
alex88qschulz, last question, the make menuconfig should be run where?15:50
alex88qschulz, if it's that hard we won't even bother doing it, my boss said to not spend more than a day, I was ok doing more for free just for fun but not weeks for sure :)15:50
qschulzalex88: if you replaced the rootfs but you reach only Starting kernel it's probably that your rootfs overrode the place in RAM where you kernel was loaded by U-Boot (I guess you went for an initramfs?)15:51
qschulzalex88: root of U-Boot git repo after having sourced the correct defconfig15:51
qschulzalex88: shameless plug:
*** psiva87 <psiva87!> has joined #yocto15:52
qschulzat least for the abstract steps and some explanations15:52
alex88ok thank you, regarding initramfs I think I'll have to read more about it, not sure what you mean :) I've just tried to use the am335x-evm config that meta-ti provides15:52
alex88thanks a lot for the link, at least I'll get more context15:52
*** aganders3 <aganders3!> has quit IRC15:53
*** w00die <w00die!~w00die@> has quit IRC15:53
*** w00die <w00die!~w00die@> has joined #yocto15:55
qschulzalex88: welcome to the wonderful world of vendor BSPs of very varying quality (more often bad than good unfortunately)15:57
alex88Definitely not a fun experience so far, but very interesting and lots to learn :)16:00
*** psiva87 <psiva87!> has quit IRC16:01
*** fl0v01 <fl0v01!~fvo@> has quit IRC16:02
*** caiortp <caiortp!> has quit IRC16:03
*** felix_inst <felix_inst!> has joined #yocto16:03
felix_instHi, I am looking to get some training with board bringup, u-boot and kernel configuration for Xilinx FPGA boards. Ideally this would be 1 on 1 sessions via zoom. Does anybody have recommendations for who can offer these services? Thanks!16:04
alex88is there a well known brand that makes industrial devices that have good compatibility with yocto? or should I just go in the machines list in the openembedded site?16:04
*** roussinm <roussinm!> has joined #yocto16:05
roussinmIf I would like to have a SDK to be able to develop on a platform that has glibc 2.19 and I can't upgrade it, do I have to absolute use the `daisy` release?16:15
*** savolla <savolla!~savolla@> has joined #yocto16:17
*** savolla <savolla!~savolla@> has joined #yocto16:18
*** savolla <savolla!~savolla@> has joined #yocto16:20
*** berton <berton!> has joined #yocto16:21
savollahi everyone! o/16:22
*** aganders3 <aganders3!~aganders3@> has joined #yocto16:22
*** kaspter <kaspter!~Instantbi@> has quit IRC16:28
*** tnovotny <tnovotny!> has quit IRC16:36
*** [Sno] <[Sno]!> has quit IRC16:37
*** yann <yann!~yann@> has quit IRC16:39
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:5256:f8ad:2da9:7c02> has joined #yocto16:42
malinusalex88: most manufactureres of SoC and SoM's make "industrial grade" versions16:44
*** manuel1985 <manuel1985!~manuel198@> has quit IRC16:49
*** yann <yann!~yann@> has joined #yocto16:50
*** vineela <vineela!vtummala@nat/intel/x-xterpqdhqhxoklew> has joined #yocto16:56
alex88malinus, I mean complete devices (with enclosure and I/O) not just SoC/SoM.. as I imagine having a compatible SoC isn't enough to get a working image OOB (but I might be wrong)16:56
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto17:04
savollaI never heard SoM before17:06
alex88Since I've started playing with yocto I had to look up most of the words :)17:07
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC17:09
*** mckoan is now known as mckoan|away17:11
*** kiwi_29 <kiwi_29!> has joined #yocto17:13
denixalex88: you mentioned your board was from another manufacturer based on TI am335x SoC - did you get BSP sources and build instructions from that manufacturer? or are you trying to straight load TI referencce BSP from meta-ti?17:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto17:18
denixalex88: as discussed above, devicetree would be the biggest difference to get a custom board up and running, especially if your manufacturer didn't follow the TI reference closely17:19
denixalex88: from the Yocto perspective, you get all the vendor BSPs here for their SoCs and their reference and evaluation platforms, like EVMs, EVks, etc.17:21
alex88denix, the latter (which isn't obviously so simple), unfortunately the manufacturer doesn't have public BSP for that (they have it since they use yocto too but they want us to use their OS)17:21
alex88denix, by vendor you mean like meta-ti for TI devices? because TI is the one doing the SoC and someone like (e.g. beaglebone) is putting the soc on a board? sorry I'm a bit confused as you can tell :)17:23
paulgRP, any idea if poky 64662290d3 /  bb d978e7b35 is still an issue 9 years on?   I spotted the double slash in alternates and went data mining to see where it came from...17:23
denixalex88: if a 3rd-party manufacturer does a custom board with enough differences from reference, they need to provide a modified BSP for that board. or at least instructions17:23
alex88denix, it can very possibly be that I'm just not able to correctly use yocto myself, as on top of meta-ti am335x-evm the only thing I've done was to get the dtb in the kernel (but probably not in uboot at this point)17:25
denixalex88: well, in your case TI is an SoC vendor. they also provide so called evaluation boards (EVM). so TI BSP officially supports own SoCs and EVMs. they you also have a different vendor who designed own board with TI SoC, so if it's too different from TI EVM, you can't straight up load TI BSP on that board - need to change configs and devicetrees, etc.17:27
denixalex88: I'm not trying to say you'd need a completely new BSP - TI BSP (kernel, u-boot, firmwares) probably covers most if not all of that custom board of yours. but you still need to configure it properly for that board17:30
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto17:31
alex88denix, I'll check the board to see if it's similar to the evm.. I just hoped, having a working OS image, that I could somehow find the configuration changes needed to get it to work with our own yocto image17:32
alex88the other option would be to find a complete product (not just a board) with an available BSP so we can skip all the work needed to get it to boot and focus on the actual OS contents17:33
denixalex88: do you get any decent documentation with the board, besides just the binary images?17:35
alex88denix, not really, it's a complete device with an enclosure not a board so they only provide documentation about the I/O and how to use it with their software17:36
denixalex88: do you need to customize u-boot? can you simply use their u-boot binary and load own kernel and rootfs?17:40
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto17:40
*** Kyubi <Kyubi!~Kyubi@> has quit IRC17:40
alex88denix, that's definitely an option, but when I've tried it was first complaining about not finding /boot/zImage then I've formatted the partition using "-O ^metadata_csum,^64bit" and it was able to get to the "Starting kernel" point and then it was stuck17:42
alex88but maybe that's because of initramfs as qschulz mentioned (which I have to understand better)17:42
alex88(stuck and restarting after a while)17:43
denixalex88: I don't know if it's possible to re-create necessary board/<vendor>/<board>/*.c and corresponding dts files from the binary image of u-boot17:43
denixalex88: check if the right uart is used for the console output to see kernel messages17:44
alex88the board/<vendor>/<board>/*.c files are for uboot?17:47
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC17:47
alex88denix, ok I'll look into how to change the UART, thank you!17:48
alex88becuase in my case the machine I use (am335x-evm from meta-ti) already sets the serial consoles with SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS3" and that matches what I see in the working SD uboot env17:49
*** yannholo <yannholo!> has quit IRC17:50
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto17:52
*** kiwi_29 <kiwi_29!> has quit IRC17:52
*** emrius <emrius!> has quit IRC17:52
denixalex88: yeah, IIRC ttyS0 is used for GP am335 and ttyS3 was added for ICE industrial variant17:54
*** kiwi_29 <kiwi_29!> has joined #yocto17:54
alex88this is what I see in the working SD kernel log
alex88so the serial port seems to be correct17:55
denixalex88: can you check what bootargs are passed to the kernel in the working logs?17:57
alex88could be the bootargs env variable from their u-boot?17:58
alex88bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait17:58
*** kiwi_29 <kiwi_29!> has quit IRC17:59
*** kiwi_29 <kiwi_29!> has joined #yocto18:00
*** kiwi_29 <kiwi_29!> has quit IRC18:03
*** kiwi_29 <kiwi_29!> has joined #yocto18:04
*** goliath <goliath!> has quit IRC18:07
*** kiwi_29 <kiwi_29!> has quit IRC18:09
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::282c> has quit IRC18:10
*** aganders3 <aganders3!~aganders3@> has quit IRC18:10
*** kiwi_29 <kiwi_29!> has joined #yocto18:11
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::282c> has joined #yocto18:13
*** renegade <renegade!~renegade@2601:241:8a00:46e0:3842:5e5:ecdd:1fd0> has joined #yocto18:16
renegadewhat would be a good way to build qt 5.12 with gatesgarth? Get meta-qt gatesgarth then make appends in my layer?18:17
*** sam__ <sam__!> has joined #yocto18:17
*** sam__ is now known as swright18:21
*** swright is now known as samw18:21
samw hey everyone. Does anybody have experience with bringing up any NXP layerscape boards? I can get along fine enough (still very new to me) with the qemu targets, but am struggling with bringing up the "real" board.18:24
*** BimBamBim <BimBamBim!531fc3b6@> has quit IRC18:40
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:5256:f8ad:2da9:7c02> has quit IRC18:41
malinussamw: SoM is System On Module. It's what you usually run with when you don't want to make your own carrier board for the SoC. Kinda like the rpi zero.18:44
malinusalex88: usually manufactureres provide working yocto18:45
alex88malinus, unfortunately that's not possible in our scenario18:46
malinushow so?18:46
*** kiwi_29 <kiwi_29!> has quit IRC18:47
denixalex88: you might want to pressure your board manufacturer to release sources to meet GPL obligations...18:48
*** kiwi_29 <kiwi_29!> has joined #yocto18:49
alex88is that somehow mandatory?18:52
denixmalinus: they got a custom board/product with binaries only (and those are quite old). the manufacturer used TI SoC in the board, but TI BSP won't boot on the board. no sources or instructions18:52
malinush-how did they end up in that situation?18:53
denixalex88: GPL license does require sources to be available on request18:54
alex88denix, what's under the GPL license that will give me the right to ask them for sources?18:55
neverpanicThe Linux kernel and busybox, for example.18:56
denixas well as u-boot18:56
alex88so theoretically just by using u-boot/busybox in their OS they would have to provide the meta layer used to build the image?18:57
samwI have found the NXP docs extremely lacking. I've spoken with a few reps from them and they are strongly pushing their LSDK over continuing to support yocto18:58
derRichardhi! one of the recipes a layer here uses SRC_URI_append_machineX and SRC_URI_append_machineY. when i run "devtool modify <recipe>", it applies patches from both SRC_URI_append_machineX and SRC_URI_append_machineY.18:58
derRichardbug? feature? :>18:58
*** aganders3 <aganders3!~aganders3@> has joined #yocto19:01
denixalex88: not sure about the yocto layer, as metadata is usually MIT licensed. but at least you can (in theory) get kernel and u-boot soures and peek into necessary configuration and devicetree19:01
derRichardstrictly speaking they don't even have to provide kernel configs nor devicetree files19:02
derRichardjust the plain sources19:02
denixalex88: those will be 7-year old code bases, of course...19:03
alex88at this point it's probably easier to find a device alternative19:03
alex88I mean, it's not us those with hundreds of bricks so there's no way we can get the investment back by fixing it19:03
alex88anyway, thank you very much denix for helping!19:04
denixderRichard: just the plain sources can get enough info, like u-boot board config, etc. but yeah, it may not be straighforward anyway and require extra work on alex88 part...19:06
denixalex88: you are certainly welcome!19:07
*** aganders3 <aganders3!~aganders3@> has quit IRC19:08
RPpaulg: I have no idea to be honest19:08
*** jobroe <jobroe!> has quit IRC19:09
paulgRP, ok, I guess I'll either just ignore the // or investigate further "someday"...19:10
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:1c6f:f48c:3ebc:63d> has quit IRC19:10
RPpaulg: I reported it, worked around it, moved on...19:11
*** mansi <mansi!> has quit IRC19:11
*** dmytro007 <dmytro007!~AndroidIR@> has joined #yocto19:25
*** dmytro007 <dmytro007!~AndroidIR@> has quit IRC19:27
*** dmytro007 <dmytro007!~AndroidIR@> has joined #yocto19:27
bluelightningderRichard: that's not a bug per se, but it is supposed to apply them to different branches (creating one per separate configuration) - does it do that?19:28
*** dmytro007 <dmytro007!~AndroidIR@> has quit IRC19:29
*** dmytro007 <dmytro007!~AndroidIR@> has joined #yocto19:29
*** dmytro007 <dmytro007!~AndroidIR@> has quit IRC19:30
*** dmytro007 <dmytro007!~AndroidIR@> has joined #yocto19:30
derRichardbluelightning: it creates also one combined branch, for whatever reasons. just found that i can stop it from doing so by passing --no-overrides to it19:34
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:f25b:aad3:93:ea00> has joined #yocto19:36
vdlWhat is the preferred tool for a python recipe? setuptools?19:40
*** dmytro007 <dmytro007!~AndroidIR@> has joined #yocto19:40
vdlI see that pyproject.toml is somehow the new thing for packaging python apps. But meta-python use a lot of setuptools3, I guess it's still the preferred (yocto) way19:53
smurrayvdl: moto-timo mentioned on last week's technical call that he's working on a transition20:06
vdlsmurray: in the meantime, it's better if I add a file and use20:08
vdlsetuptools3, right?20:08
vdl(until a new yocto release switches to pyproject.toml20:09
smurrayvdl: setuptools3 is what is supported today AFAIK20:10
smurrayvdl: moto-timo may pop on at some point and be able to describe his plans20:11
vdlI'll stick with for now then.20:12
rburtonfeel free to write a class for the toml stuff20:25
rburtonthe sooner someone starts a class the sooner its supported20:25
RPvdl: I suspect someone will write a class and then we'll migrate over as newer releases come out as we're doing with meson for example20:29
rburtonvdl: isn't setuptools mostly merged into distutils these days?20:32
rburtoni admit i don't use it that heavoy20:32
rburtonerm, heavily20:32
savollahey guys what is the most reliable distro for yocto? I'm having troubles on manjaro as my host. I want to pull a docker image and build there20:39
savollathey say ubuntu is the most stable one but which version?20:40
felix_instsavolla, I had good luck with Ubuntu 18.0420:40
savollaoh thanks!20:40
felix_instdepends on the poky version you want20:40
savollafelix_inst: I want to build for bbb20:40
savollathis is my first experience with yocto20:40
felix_instsavolla, I used 18.04 with zeus. 20.04 would not work. dunfell may be the other way around20:41
savollazeus and dunfell. they are yocto releases right?20:41
savollabranches sorry20:42
Crofton|cloudsavolla: also look at pyrex20:42
felix_instzeus is 3.0.x20:42
felix_instdunfell appears to be 3.1.x20:43
savollaguys I really don't understand the yocto terminology yet. those are yocto branches? which we specify with -b option while cloning?20:43
felix_instthe last argument is the branch. the -b flag just makes you create a local branch at checkout20:44
felix_instit's a git thing20:44
savollaI looked at yocto reference but it is very long and I don't have the time at the moment. but deffinitely will read the manual later. maybe you guys can guide me to build a minimal image for bbb20:45
felix_instsavolla, I am pretty much in the same boat. So I don't know how to help you there. I would imaging BBB has a quickstart tutorial20:46
*** bps <bps!~bps@> has quit IRC20:47
*** kiwi_29 <kiwi_29!> has quit IRC20:48
denixsavolla: dunfell 3.1 is the current yocto LTS release. many yocto layers have separate branches specific to the release.
savollathanks anyway felix_inst . I also need to make a Qt application for bbb which displays some sensor information. I tryed to cross compile my application with qtcreator but didn't work. so someone told me that I need to create an image with yocto first. I really don't know if this is true. I'm asking you guys now20:53
savolladenix: oh thank you!20:53
savollaI get it now20:53
*** richbridger <richbridger!> has joined #yocto20:57
felix_instsavolla, there is a qt layer - and you should be able to generate the cross compiler toolchain after the main build20:58
*** kiwi_29 <kiwi_29!> has joined #yocto21:03
savollafelix_inst: really? that is really cool then.. where can I get that layer?21:05
savollaI just started with yocto and watching this tutorial . sorry for my annoying questions again21:06
*** kiwi_29 <kiwi_29!> has quit IRC21:06
felix_instsavolla, I have not used it myself, so take it with a grain of salt. This is the layer I *think* might be useful:
savollafelix_inst: thank you so much! I'll definitely try it.21:11
felix_instsavolla, yw, I hope that's what you need21:12
*** berton <berton!> has quit IRC21:15
*** kiwi_29 <kiwi_29!> has joined #yocto21:15
*** B0ned1ger <B0ned1ger!> has joined #yocto21:16
renegadesavolla you will need to pull in meta-qt build your app. The recipe should include inherit qmake5 if you are using qmake. You can then also build the SDK which you can integrate with qt creator to cross compile and deploy to your machine21:17
*** mansi <mansi!> has joined #yocto21:17
*** sbach <sbach!~sbachmatr@> has quit IRC21:18
*** vineela <vineela!vtummala@nat/intel/x-xterpqdhqhxoklew> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has joined #yocto21:18
*** kiwi_29 <kiwi_29!> has quit IRC21:18
savollarenegade: yeah this is exactly what I was planning for :) thank you21:19
*** B0ned1ger <B0ned1ger!> has quit IRC21:21
*** kiwi_29 <kiwi_29!> has joined #yocto21:24
*** kiwi_29 <kiwi_29!> has quit IRC21:28
*** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto21:28
*** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has quit IRC21:32
moto-timovdl: smurray: oe-core currently only supports setuptools and distutils. When we last started looking at new packaging methods, upstream wasn't ready yet. I forget the details. It's worth another look, but any new bbclass should really be landing in oe-core first IMHO.21:32
*** vineela <vineela!~vtummala@> has joined #yocto21:33
*** kiwi_29 <kiwi_29!> has joined #yocto21:34
moto-timovdl: smurray: I'm more interested in a common ptest-pytest class for my own development at the moment.21:34
*** kiwi_29 <kiwi_29!> has quit IRC21:38
*** savolla <savolla!~savolla@> has quit IRC21:41
*** karlyeurl <karlyeurl!~Karlssel@2001:41d0:8:9a4b::1> has joined #yocto21:47
*** B0ned1ger <B0ned1ger!> has joined #yocto21:48
*** vineela <vineela!~vtummala@> has quit IRC21:48
*** vineela <vineela!vtummala@nat/intel/x-gnsmbbtsehajoupa> has joined #yocto21:49
*** B0ned1ger <B0ned1ger!> has quit IRC21:52
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:03
*** mansi <mansi!> has quit IRC22:06
*** mansi <mansi!> has joined #yocto22:14
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:14
*** renegade <renegade!~renegade@2601:241:8a00:46e0:3842:5e5:ecdd:1fd0> has quit IRC22:14
*** diego_r <diego_r!> has quit IRC22:22
*** Yumasi <Yumasi!> has quit IRC22:33
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:f25b:aad3:93:ea00> has quit IRC22:50
*** agust <agust!> has quit IRC22:52
*** dev1990 <dev1990!> has quit IRC22:58
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has joined #yocto23:03
*** Kyubi <Kyubi!~Kyubi@> has quit IRC23:03
*** Gaffel <Gaffel!> has quit IRC23:14
*** vineela <vineela!vtummala@nat/intel/x-gnsmbbtsehajoupa> has quit IRC23:24
*** oberstet_ <oberstet_!~oberstet@> has joined #yocto23:32
*** oberstet <oberstet!~oberstet@> has quit IRC23:34
*** vineela <vineela!vtummala@nat/intel/x-wqbqhugetegeewps> has joined #yocto23:47
*** B0ned1ger <B0ned1ger!> has joined #yocto23:49
*** B0ned1ger <B0ned1ger!> has quit IRC23:53
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:b936:dc55:2635:c80d> has quit IRC23:59

Generated by 2.17.2 by Marius Gedminas - find it at!