Wednesday, 2020-11-25

*** Scoutboy <Scoutboy!~quassel@> has quit IRC00:25
*** kpo_ <kpo_!> has quit IRC00:31
*** kpo_ <kpo_!> has joined #yocto00:31
*** junland <junland!~junland@> has quit IRC00:44
*** roussinm <roussinm!> has quit IRC01:03
*** B0ned1ger <B0ned1ger!> has joined #yocto01:21
*** B0ned1ger <B0ned1ger!> has quit IRC01:25
*** ahadi <ahadi!~ahadi@> has quit IRC01:33
*** ahadi <ahadi!~ahadi@> has joined #yocto01:34
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC01:49
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has quit IRC01:52
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has joined #yocto01:53
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:58
*** stephano <stephano!> has quit IRC02:24
*** wbn <wbn!~badegg@2607:5300:60:2ca::1> has joined #yocto02:35
*** rcw <rcw!~rcwoolley@> has quit IRC02:51
*** ericch <ericch!> has quit IRC02:57
*** roussinm <roussinm!> has joined #yocto03:01
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has quit IRC03:03
*** camus <camus!~Instantbi@> has joined #yocto03:08
*** kaspter <kaspter!~Instantbi@> has quit IRC03:08
*** camus is now known as kaspter03:08
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has joined #yocto03:11
*** B0ned1ger <B0ned1ger!> has joined #yocto03:22
*** B0ned1ger <B0ned1ger!> has quit IRC03:26
*** vineela <vineela!~vtummala@> has quit IRC03:50
*** kpo_ <kpo_!> has quit IRC04:13
*** kpo_ <kpo_!> has joined #yocto04:14
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:26
*** ahadi <ahadi!~ahadi@> has quit IRC04:30
*** ahadi <ahadi!~ahadi@> has joined #yocto04:31
*** camus <camus!~Instantbi@> has joined #yocto04:39
*** kaspter <kaspter!~Instantbi@> has quit IRC04:39
*** camus is now known as kaspter04:39
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC04:43
*** goliath <goliath!> has joined #yocto04:55
*** fancer <fancer!fancer@gateway/web/> has quit IRC04:55
*** fancer <fancer!fancer@gateway/web/> has joined #yocto04:56
*** oberstet <oberstet!~oberstet@> has joined #yocto04:57
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:06
*** B0ned1ger <B0ned1ger!> has joined #yocto05:23
*** B0ned1ger <B0ned1ger!> has quit IRC05:27
*** davidinux <davidinux!~davidinux@> has quit IRC05:43
*** davidinux <davidinux!~davidinux@> has joined #yocto05:45
*** kaspter <kaspter!~Instantbi@> has quit IRC05:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:51
*** camus <camus!~Instantbi@> has joined #yocto05:53
*** camus1 <camus1!~Instantbi@> has joined #yocto05:54
*** camus <camus!~Instantbi@> has quit IRC05:54
*** kaspter <kaspter!~Instantbi@> has quit IRC05:55
*** camus1 is now known as kaspter05:55
*** pharaon2502 <pharaon2502!> has quit IRC06:19
*** kpo_ <kpo_!> has quit IRC06:19
*** camus <camus!~Instantbi@> has joined #yocto06:20
*** kaspter <kaspter!~Instantbi@> has quit IRC06:20
*** camus is now known as kaspter06:20
*** kpo_ <kpo_!> has joined #yocto06:20
*** w00die <w00die!~w00die@> has quit IRC06:33
*** AndersD <AndersD!> has joined #yocto06:34
*** w00die <w00die!~w00die@> has joined #yocto06:35
*** B0ned1ger <B0ned1ger!> has joined #yocto06:35
*** beneth <beneth!> has joined #yocto06:35
*** AndersD_ <AndersD_!> has joined #yocto06:37
*** AndersD <AndersD!> has quit IRC06:40
*** jobroe_ <jobroe_!> has joined #yocto06:41
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto06:51
*** kaspter <kaspter!~Instantbi@> has quit IRC06:54
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto06:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:55
*** creich <creich!> has quit IRC06:57
*** creich <creich!> has joined #yocto06:57
*** grembeter <grembeter!c108287e@> has joined #yocto07:08
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:13
*** zandrey <zandrey!~zandrey@> has joined #yocto07:15
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:16
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC07:24
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto07:26
*** frsc <frsc!> has joined #yocto07:26
*** Shikadi <Shikadi!> has quit IRC07:29
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC07:30
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto07:32
*** mbulut <mbulut!> has joined #yocto07:44
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto07:45
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:46
*** agust <agust!> has joined #yocto07:46
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC07:48
*** mihai- is now known as mihai07:48
*** mbulut_ <mbulut_!> has joined #yocto07:48
*** mbulut_ <mbulut_!> has quit IRC07:49
*** mbulut <mbulut!> has quit IRC07:50
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC07:51
*** roussinm <roussinm!> has quit IRC07:51
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto07:52
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:53
LetoThe2ndmoto-timo: i think that must have been the 5 minutes in my life with the most hilarious tweeting so far. you beat me to it!07:54
LetoThe2ndoh and yo dudX07:54
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC08:00
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto08:02
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto08:02
*** T_UNIX <T_UNIX!> has joined #yocto08:02
*** mckoan|away is now known as mckoan08:04
mckoanyo morning :-)08:04
*** Yumasi <Yumasi!> has joined #yocto08:15
*** gpanders <gpanders!> has quit IRC08:21
*** Yumasi <Yumasi!> has quit IRC08:30
*** gpanders <gpanders!> has joined #yocto08:31
*** B0ned1ger <B0ned1ger!> has quit IRC08:35
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto08:35
*** Yumasi <Yumasi!> has joined #yocto08:35
*** T_UNIX <T_UNIX!> has quit IRC08:42
*** Yumasi <Yumasi!> has quit IRC08:51
*** Yumasi <Yumasi!> has joined #yocto08:57
* qschulz waves08:59
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:a66:4cbe:68f8:d8f> has joined #yocto09:04
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC09:09
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto09:10
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC09:11
*** manuel1985 <manuel1985!> has joined #yocto09:12
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto09:12
*** Yumasi <Yumasi!> has quit IRC09:13
*** dleppich <dleppich!~Thunderbi@> has joined #yocto09:14
*** Yumasi <Yumasi!> has joined #yocto09:18
*** extor <extor!extor@unaffiliated/extor> has quit IRC09:21
*** extor <extor!extor@unaffiliated/extor> has joined #yocto09:22
*** Yumasi <Yumasi!> has quit IRC09:24
*** Yumasi <Yumasi!> has joined #yocto09:24
wyrehow can I check the env BSPDIR ?09:27
*** extor <extor!extor@unaffiliated/extor> has quit IRC09:29
wyreI don't get why it's not finding the folder
*** extor <extor!extor@unaffiliated/extor> has joined #yocto09:29
wyreLetoThe2nd, I thought when I use `bitbake -e` it prints the whole environment09:29
LetoThe2ndwyre: hm, almost. it prints the final result of the recipe evaluation, which includes all variables and their evaluation that have happened in there.09:30
wyreLetoThe2nd, well, then how can I figure out why it's failing?09:31
LetoThe2ndi have no idea what is failing?09:32
LetoThe2ndwyre: just checked: BSPDIR is not something that exists in poky09:35
LetoThe2ndwyre: so i have the strong feeling that you are battling some craziness by your BSP vendor.09:35
mihaiBSPDIR is something that the freescale layers are using09:36
* LetoThe2nd is out then.09:36
wyreLetoThe2nd, it's not finding the directory '${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp' but it's there09:36
LetoThe2ndlike i said, BSP vendor suplied craziness. i do not intend to support this.09:37
LetoThe2nd(other might have different opinions, of course)09:37
wyreLetoThe2nd, you mean in this repo?
mihaiwyre: you need to source their environment setup script, not poky/oe-init-build-env09:38
*** manuel1985 <manuel1985!> has quit IRC09:38
wyremihai, I've done that09:38 in fact09:38
mihaifrom what layer is that?09:38
wyremihai, meta-fsl-bsp-release09:39
LetoThe2ndwyre: i will not even look that up. one time you refer to engicam, another time you refer to toradex. if they sell you hardware, then also please contact their support.09:39
* LetoThe2nd will be silent then and refer to mihai09:39
wyremihai, then what do you think is not finding the layer directory? πŸ€”09:40
mihailooking now, there was a gimmick there that defined that variable09:42
*** gourve_l <gourve_l!> has quit IRC09:42
*** gourve_l <gourve_l!> has joined #yocto09:43
wyrein fact I also think the vendor is not a good one, I think the meta-engicam has a lot of dependencies that I don't need09:44
mihaihm, you should have this in your bblayers.conf09:44
wyrelike meta-qt509:44
mihaiBSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"09:44
wyremihai, should I include that in the bblayers.conf?09:45
wyremihai, why is not this generated? πŸ€”09:46
mihaiafaik. meta-fsl-bsp-release should be based on the freescale layers, and that's what they do09:46
*** grembeter <grembeter!c108287e@> has quit IRC09:47
mihaiit uses a template containing bblayers.conf which defines it,
*** gpanders <gpanders!> has quit IRC09:48
dleppichIs anyone using kas for yocto projects and has setup a CI pipelin with it? Even better if someone has done it with gitlab CI :)09:49
LetoThe2nddleppich: yes, no and no :)09:52
LetoThe2ndrespectively, we're kicking it off with jenkins, but thats about it.09:52
wyremihai, for some reason when I run I'm not having the bblayers.conf template with BSPDIR := ...09:52
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has quit IRC09:53
dleppichLetoThe2nd: Hmm, I haven't worked with CI that much before.. But in my imagination it shouldn't be that hard, right? I just need to have a docker image with python and do the kas setup there (venv, install kas) and start the build afterwards, right?09:54
mihaiwyre: well...09:54
* mihai shrugs 09:55
LetoThe2nddleppich: it depends a bit on the use case i think. where the artifacts are being put, if there are additional parameters to be piped into the build.09:55
wyrewhen I source, I mean, mihai 😊09:55
LetoThe2nddleppich: paulbarker has done a presentation on ci pipelines at ELC-NA, let me see if i can find the video09:56
dleppichLetoThe2nd: I'm in the stage of trying out stuff, so my only usecase is to make GitLab CI build something (e.g. a core-image-minimal) with kas + yocto.09:56
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has joined #yocto09:57
LetoThe2nddleppich: best inspiration i can offer is
mckoanwyre: Instead of continuing to make changes without knowledge of the facts I suggest you start over with a new installation, document all the steps you take and if necessary put them on pastebin so that we can understand what you are doing.09:57
dleppichLetoThe2nd: Thanks! I'll have a look at it :)09:57
LetoThe2nddleppich: have fun!09:57
wyremckoan, that's exactly what I was trying09:58
wyrebut I have better results with the bsp provided by engicam, the point is the sources are not git repos, I think they made their changes09:58
mckoanwyre: FYI We are working on several projects based on Engicam MicroGea MX6ULL and STM32. Apart from a few minor fixes everything works out-of-the-box.09:59
mckoanwyre: period.09:59
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:a812:f255:469e:d33e> has joined #yocto10:03
*** davidinux <davidinux!~davidinux@> has quit IRC10:03
wyremckoan, you mean with the bsp provided by Engicam?10:05
*** gnslu2-lo <gnslu2-lo!> has quit IRC10:05
*** davidinux <davidinux!~davidinux@> has joined #yocto10:05
*** leon-anavi <leon-anavi!~Leon@> has quit IRC10:05
*** nslu2-log <nslu2-log!> has joined #yocto10:05
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:05
*** gpanders <gpanders!> has joined #yocto10:08
wyremckoan, remember that I'd like to build warrior while bsp ships pyro10:09
* LetoThe2nd is angry. coffee maker at office is broken.10:13
qschulzwyre: depending on what you need from the BSP vendor, just take the recipes you want and ditch the vendor BSP10:18
wyreqschulz, that's what I'm trying, πŸ˜† so I don't need the meta-engicam layer? πŸ€”10:18
wyreyou mean could I just build warrior and boot it in the board?10:19
mcfriskwyre: BBMASK away everything that you don't need from a BSP layer10:28
mcfrisksome BSP layers come with a kitchen sink of SW modifications which tie them heavily to a yocto release10:29
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has joined #yocto10:31
wyremcfrisk, I don't actually know what I don't need πŸ˜†10:31
LetoThe2ndmcfrisk: i actually could need a new kitchen sink. mine's clogged.10:32
RPLetoThe2nd: there must be a video for "plunging new depths" to answer that comment :)10:34
kanavin_homeRP: took a while to sort, but world reproducibility patchset is now being built by a-full
LetoThe2ndRP: i should create meta-pΓΌmpel. too bad it translates badly, e.g. it doesn't sound half as funny in english (meta-plunger)10:36
wyremcfrisk, how can I identify what I don't need from here?
wyreI'd say I just need the recipes-core10:37
kanavin_homeRP: I spent an awful amount of time getting go and its consumers to reproduce, and got there, but not happy with the currently hacky nature of the fixes. So that's taken out, and will be handled later10:37
LetoThe2ndRP: and as there is no metallic element named after it in the periodic system so far, i unfortunately am not permitted to do so :(10:37
RPkanavin_home: that is quite an achievement getting the list down to that, nice work!10:39
RPkanavin_home: go sounds a pain. Is there interest in that upstream?10:39
RPLetoThe2nd: some things don't translate so well, for better or worse :)10:40
mcfriskwyre: you need to check, remove, re-test, iterate over this. start by checking what is currently in your product images. been there too, but after BBMASKing 90% stuff away, life suddenly becomes much easier with yocto updates etc10:40
RPkanavin_home: zeddii will have perf fixed in no time ;-)10:41
RP(we're usually lucky if it builds :/)10:41
LetoThe2ndtodays lesson learnt: trimming/recoding the live coding session recordings in openshot is a stupid idea.10:41
wyremcfrisk, by now I'm building just yocto10:42
qschulzwyre: you said the bsp vendor only supports pyro but you send one that supports warrior, you're confusing us :)10:43
wyreqschulz, well, for this board the BSP shipped comes with pyro, the branch warrior is what I'm trying to use to build a minimal warrior version10:44
wyrewithout qt, gnome, or layers like that10:45
mcfriskwyre: you are likely not building yocto, e.g. world. you build an image. like core-image-minimal.10:45
wyremcfrisk, core-image-saato10:45
kanavin_homeRP: there is some interest, but a lot of the pain comes from go tooling writing buildid hashes into the output, and those hashes being extremely sensitive to anything in the build environment. E.g. if ldflags contains full build paths (which it does), that will affect the hash.10:45
wyres/saato/sato/ in fact10:45
mcfriskwyre: ok, then do you need all of that, and which ones of the SW components need BSP adaptations. that depends on target HW and machine config and use cases with sato image.10:46
RPkanavin_home: hmm, I can imagine how that becomes painful :(10:46
RPkanavin_home: I just ran a build of your branch on fedora33 btw. That runs with a different host umask and uncovered a load more reproducibility issues :(10:47
kanavin_homeRP: also, it's just plain difficult to debug hash issues like that as the toolchain wasn't designed for it, and it's supposed to be something go users never have to worry about10:47
RPkanavin_home: it does sound like the kind of thing the go people need to be made aware of10:48
wyremcfrisk, what's the difference between -sato, -minimal and -base images?10:48
RPkanavin_home: reproducible-builds people also probably have an interest10:48
kanavin_homeRP: yeah, I have no idea how receptive they would be to something coming from the yocto project. Google tends to do everything in a self-contained manner.10:48
kanavin_home(the go folks)10:49
RPkanavin_home: right, you'd think they'd want to try and support reproducibility but who knows...10:49
kanavin_homeRP: at the moment go is at the fringes of dependency tree, so its non-reproducibility is not a major item, but that could change quickly10:50
RPkanavin_home: right, that is a worry :/10:50
mcfriskwyre: look at the recipes and packages that get installed to them. sato is a gnome image, minimal is rally minimal to boot into a shell.10:50
RPkanavin_home: it is really nice to have the list trimmed down to a definitive set of packages though :)10:51
kanavin_homeRP: yes, let's see if a-full run reveals any additional items10:52
kanavin_homeRP: I fixed the biggest items (in size) at least - webkit, llvm, etc10:52
kanavin_homeRP: quite often it's full build paths somehow leaking into target, especially the source code in -src often refers to them when it's generated10:53
RPkanavin_home: right, I remember starting this journey and thinking it was near impossible :)10:56
RPkanavin_home: nice work on webkit and llvm, they're big beasts10:57
kanavin_homeRP: it's tedious indeed, best taken in smaller chunks10:58
RPkanavin_home: right, that is how we end up here today :)10:58
RPkanavin_home: but having a target list is a big win10:58
*** kpo_ <kpo_!> has quit IRC11:08
*** kpo_ <kpo_!> has joined #yocto11:09
wyremcfrisk, the point is when I use meta-engicam (the bsp layer) I have to use a different target from core-image-minimal, which is the one that I'd like to build πŸ€”11:14
mcfriskwyre: no, for your product, you need to define an image. for a proof of concept and with limited use cases, one of the default images like core-image-minimal (boot to shell) or core-image-sato (boot to a GUI shell) can work. even without a BSP layer, you need to pick and choose what you want to be in your image.11:16
LetoThe2ndmcfrisk: hint:
*** davidinux <davidinux!~davidinux@> has quit IRC11:28
*** davidinux <davidinux!~davidinux@> has joined #yocto11:29
*** yann <yann!~yann@> has quit IRC11:40
*** yann <yann!~yann@> has joined #yocto11:40
*** mbulut <mbulut!> has joined #yocto11:56
*** Yumasi <Yumasi!> has quit IRC11:59
*** dleppich <dleppich!~Thunderbi@> has quit IRC12:04
*** dleppich <dleppich!~Thunderbi@> has joined #yocto12:05
*** camus <camus!~Instantbi@> has joined #yocto12:14
*** jobroe <jobroe!> has joined #yocto12:14
*** kaspter <kaspter!~Instantbi@> has quit IRC12:15
*** camus is now known as kaspter12:15
*** jobroe_ <jobroe_!> has quit IRC12:15
bachpDoes somebody know the status of the poky tests in meta/lib/oeqa/sdk/cases/? I tried to run them via oe-test but this imediatly failed with an error: ModuleNotFoundError: No module named 'bb'. Is there another way to run these tests that I'm not aware of?12:26
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC12:32
*** creich <creich!> has quit IRC12:34
*** creich_ <creich_!> has joined #yocto12:34
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto12:34
RPbachp: bitbake <image> -c testsdk12:36
bachpRP:  Thanks, is the oe-test scripts not intended to run directly?12:37
bachpRP:  When I run -c testsdk I get: Task do_testsdk does not exist for target core-image-sato12:40
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:40
bachpI was missing INHERIT += "testsdk"12:44
*** tgoodwin <tgoodwin!> has joined #yocto12:45
RPbachp: ah, yes, you need that. autobuilder does run them all the time so they do work/pass12:51
*** sagner <sagner!~ags@2a02:169:3df5::4db> has quit IRC12:53
*** sagner <sagner!~ags@2a02:169:3df5::979> has joined #yocto12:54
*** Ben7 <Ben7!> has joined #yocto12:57
mckoantraining time, bye12:59
*** mckoan is now known as mckoan|away12:59
*** Ben7 <Ben7!> has quit IRC13:03
*** grembeter <grembeter!c108287e@> has joined #yocto13:08
*** schu-r <schu-r!52956b02@> has joined #yocto13:10
schu-rFor development Purpose i need to comile the Programms static. So I let yocto build a SDK and added libstdc++-staticdev and ind SDKIMAGE_FEATURES i added staticdev-pkgs. When I install the SDK Compiing works but at Link time I get 'cannot find -lcrypt / -lpcre' I assume that these libs are not in the statsic form. Is the a chance to get all Libs13:14
schu-ralso as Static into the SDK?13:14
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto13:14
*** tgoodwin <tgoodwin!> has quit IRC13:22
*** JaBen1 <JaBen1!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto13:25
*** tgoodwin <tgoodwin!> has joined #yocto13:25
*** tgoodwin <tgoodwin!> has joined #yocto13:25
*** mbulut <mbulut!> has quit IRC13:32
rburtonschu-r: poky turns off static libraries, so that might be the problem13:35
*** B0ned1ger2 <B0ned1ger2!> has quit IRC13:35
*** B0ned1ger <B0ned1ger!> has joined #yocto13:35
JaBen1Hi, I am trying to change the hard assigned KERNEL_IMAGETYPE from upstream machine config without having to create a fork. So I though I could do a `KERNEL_IMAGETYPE_append = " uImage-gzip"` and a `KERNEL_IMAGETYPE_remove = "zImage"` in my local config, as it is not weak assigned. This however gives me a QA Issue:  `kernel-image-uimage-gzip is listed in PACKAGES multiple times`. What would be the proper way to deal with this?13:35
rburtonschu-r: if you need static libraries you should create your own distro that doesn;t disable static libraries13:36
schu-rrburton: I already have the glibc static. But not the others.13:37
*** emrius <emrius!> has joined #yocto13:37
SaurRP: I've sent patches now for the problems I've seen with symbolic links and PSEUDO_IGNORE_PATHS.13:39
*** RobertBerger <RobertBerger!> has quit IRC13:43
*** grembeter <grembeter!c108287e@> has quit IRC13:47
*** tgoodwin is now known as tgoodwin[away]13:49
*** stenscott <stenscott!c7f723c3@> has joined #yocto13:56
* zeddii reads and chuckles13:57
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC13:59
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto14:01
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto14:02
JaBen1So I changed KERNEL_IMAGETYPE to a weak assignment for test purposes and tried to overwrite it in my local config, resulting in the same error. So it seems you cannot simply overwrite this variable?14:16
LetoThe2ndJaBen1: it depends (TM)14:19
*** schu-r <schu-r!52956b02@> has quit IRC14:19
LetoThe2ndJaBen1: the one true way (TM, too) is to look at the full evaluation history of the variable (bitbake -e) to actually understand whats going on.14:19
rburtonzeddii: do you have plans to move linux-yocto to 5.10 when it comes out?14:25
zeddiiyep. -dev already has it cooking. 5.10 will become the LTS in master, and probably 5.11 as the "newer" kernel in the release.14:26
rburtonawesome, thanks14:26
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC14:27
LetoThe2ndzeddii: what was the phrase you had in lyon? "a system is always one level up from your own knowledge?" or something similar14:29
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC14:30
zeddiiyes. I do recall saying something like that, as part of my containers thing. or was it the binary distro stuff.14:31
*** rob_gries <rob_gries!> has joined #yocto14:31
zeddiibetter than saying "it makes me feel dumb"14:31
zeddiiwhich is true as well :)14:31
*** habing_ <habing_!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC14:31
LetoThe2ndzeddii: but it was something made up on the spot, not a commonplace saying?14:32
rob_griesHas anyone setup nodejs with pm2 on top of Yocto? I have a nodejs developer wanting this functionality added into our BSP, and I was wondering if anyone had any tips that I could leverage.14:32
zeddiiit is something that I've heard locally to me, but that definitely doesn't make it common :D14:32
LetoThe2ndzeddii: i see14:32
emriusHey everyone, I just posted another question on SO just wanted to say hi to have the possibility to shed some light on that issue interactively :)
zeddiiof course from where I'm from, there's both unique dialects of english, french and combination of the two.14:33
LetoThe2ndrob_gries: other than pm2 having quite a number of dependencies and therefore maybe being problematic to package, i don't think it sustantially differes from other npm things.14:34
*** B0ned1ger <B0ned1ger!> has quit IRC14:35
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto14:35
rob_griesLetoThe2nd: I see... I just asked him to add the npm package into his package.json to see if we can get it in that way.14:36
LetoThe2ndrob_gries: the two main problems with npm generally are 1) nondeterministic behaviour, like things being fetched outside the fetches and not using the DL_DIR and 2) licensing woes, as its close to impossible to set your recipes license correctly if it actually pulls in a tree of dependencies.14:40
*** grembeter <grembeter!c108287e@> has joined #yocto14:42
JaBen1@LetoThe2nd: hm... looking at this, I am not quite sure how to read it :D but for some reasons `#   override[kernel-image-uimage-gzip]:set kernel.bbclass:96 [__anon_108__mnt_poky_meta_classes_kernel_bbclass]` appears twice...14:43
JaBen1which seems of to me14:44
LetoThe2ndJaBen1: put the evaluation history into a pastebin, then we can have a look14:44
LetoThe2ndJaBen1: too secure for me, browser stuck on "decrypting"14:47
qschulzemrius: those are just addresses in the storage medium14:47
qschulzyou put the env more or less wherever you want14:47
qschulzprovided it's not overwritting or overwritten by something else14:47
qschulzyes they need to be sync'ed14:47
qschulz(fw_conf and CONFIG_ENV_OFFSET)14:48
qschulzyou might want to define CONFIG_ENV_SIZE also IIRC14:48
emriusqschulz: Thanks! That helped a lot!14:48
JaBen1@LetoThe2nd: give it some time... the document is just pretty huge :D14:49
emriusDefining CONFIG_ENV_SIZE appears reasonable. Great :)14:49
LetoThe2ndJaBen1: I gave until the tab crashed14:49
JaBen1@LetoThe2nd: hm... worked for me... give me a sec. will try a different service14:50
emriusbeer counter: qschulz += 1. Let me know if you are ever around in Berlin ;)14:50
LetoThe2ndJaBen1: the some-ten-ish-lines of the variable evaluation would probably enough.14:50
qschulzemrius: bitbake += or python += :p?14:50
qschulzemrius: pleasure to help, no beer needed :)14:51
LetoThe2ndqschulz: VHDL +=14:51
emrius:) python14:51
qschulzLetoThe2nd: *sigh* the joke being qschulz = 2 in python but qschulz = 11 in bitbake :)14:51
qschulzactually qschulz = 1 1 but eh14:51
LetoThe2ndqschulz: thou shalt prefer bitbake then!14:52
emrius... Ah... python was just a dummy guess. Didn't get that one either. Another pythonic `+= 1` for clarification14:52
JaBen1@LetoThe2nd: Should mention I'm currently still stuck on thud14:55
*** roussinm <roussinm!> has joined #yocto14:57
LetoThe2ndJaBen1: i don't think that it makes a difference, but of course it can't hurt if you diff meta/classes/kernel.bbclass between thud and dunfell14:57
LetoThe2ndJaBen1: i see that there actually has been quite some changes. maybe even
LetoThe2ndJaBen1: so yes, i take back my last post and conclude it might be caused by thud.14:59
LetoThe2ndzeddii: maybe can comment.14:59
*** ericch <ericch!> has joined #yocto15:00
JaBen1@LetoThe2nd hm... that would suck, as I don't see myself being to upgrade in the near feature, as ADI only supports thud atm. Was the log able to provide any useful info?15:02
LetoThe2ndJaBen1: to me it seems like the function in kernel.bbclass misbehaves and duplicates the setting. but for what reason i cannot tell, nor if the current state also exhibits this behaviour. if it is still present on dunfell you are invited to file a bugreport, in any other case, well, bad luck for you. then you'll have to pester ADI or figure it out yourself.15:05
qschulzJaBen1: what do you need from ADI?15:06
qschulzif it's just a BSP, then migrate to newer stuff by cherry-picking only what you need (kernel, bootloader, a few patches here and there)15:06
qschulzditch the rest15:06
LetoThe2ndqschulz: it think that starts to qulify as yocto chant #2: "cherrypick the bsp, ditch the rest."15:07
qschulzLetoThe2nd: yeah, it's just *recipes* and kernel and bootloader are so independent from the rest of the system (heck it's usually not even part of the rootfs) that you can just take them out of your vendor crappy BSP layer15:08
JaBen1@LetoThe2nd: Ok, I'll try to reproduce the problem on dunfell15:09
*** emrius <emrius!> has quit IRC15:09
LetoThe2ndqschulz: you don't hear me disagreeing, do you? ;-)15:09
wyreLetoThe2nd, why don't you run an image inside tmp/deploy/images/quemuarm in here ?15:10
JaBen1@qschulz: That is the long term plan, working on it :D15:10
LetoThe2ndqschulz: but i still keep the position that its not my duty to handhold everybody burned by vendor bsps through the process.15:10
LetoThe2ndwyre: you men, why i don't pass the path to the image?15:11
wyreLetoThe2nd, that's it15:12
LetoThe2ndwyre: because magic
qschulzJaBen1: honestly, sometime the layer is so bad that it might take you less time to just cherry-pick whatever you need15:13
qschulzJaBen1: FYI, we don't even try anymore, we just pick the kernel, bootloader, optee and atf and that's it15:13
qschulzheck, we even write the recipes ourselves :p15:13
LetoThe2ndwyre: in a nutshell - if you don't give runqemu stuff, it mostly can figure out from the last build.15:14
qschulzbut tbf, we don't use any proprietary blob from our vendor so that helps15:14
qschulz(.e.g no gpu, vpu, etc...)15:14
JaBen1@qschulz: yeah we have to include blob drivers for DSP... no fun15:16
JaBen1I hoped to streamline the whole process and use more upstream to reduce maintenance work... but it seems like that won't be happening :(15:17
qschulzJaBen1: the thing is, if you invest time and money now, it should be relatively easy to upgrade in the near future15:18
qschulzJaBen1: the longer you wait, the more it'll cost and the more painful it'll be15:18
JaBen1@qschulz: yep... that's what I'm trying to do. We are currently stuck on a yocto build environment that effectively hasn't been touched in 2 years and now I have taken up the ungrateful task to improve the situation... :/15:20
qschulzJaBen1: I'll put you in my prayers15:21
JaBen1thanks :D15:21
qschulzJaBen1: honestly that's the best way to learn things :)15:23
qschulz(not pray, upgrade :) )15:23
*** pharaon2502 <pharaon2502!> has joined #yocto15:38
wyreso you say I need to define a custom image? I mean, .. cannot I use the recipes in the BSP?15:40
LetoThe2ndwyre: you don't WANT to use pre-made images. thats basically yocto rule #215:42
LetoThe2nd(#1 is recipe data is local, conf data is global!)15:43
wyreLetoThe2nd, where can I read the yocto rules?15:43
LetoThe2ndwyre: here :)15:43
*** AndersD_ <AndersD_!> has quit IRC15:44
wyreLetoThe2nd, so then the point is to take advantage of the BSP layer to make my own layer? πŸ€”15:44
qschulzwyre: not really no15:45
qschulzyou build a system by having a collection of layers15:45
qschulzand building one specific image for a specific machine using specific distro settings15:45
LetoThe2ndwyre: no, you still don't get it. a BSP layer shall give you the infrastructure to use a board. and its your duty to add a layer on top that make the now booting board do what you want.15:45
qschulzBSP layer is for the "for a specific machine" part15:46
wyreLetoThe2nd, but then I need all layers which the BSP depends on15:46
wyrethe BSP layer depends on, I mean15:46
qschulzwyre: a BSP layer should depend on almost nothing15:46
LetoThe2ndwyre: but again - i strongly advise to get some proper training to explain stuff in a coherent, curated manner. i feel you are wasting a lot of time and effort, (including that of helpful people here), just because you're basically cheap.15:46
qschulzand you can take only the parts you're ihterested in (kernel, bootloader, optee, atf, whatever)15:47
qschulzthose usually don't depend on anything else than openembeded-core or at worst poky15:47
LetoThe2ndwyre: we have tried to explain the use cases and proper, working usage of a BSP layer at least 5 times now. i really think the community duty is fulfilled here. (shame on me letting myself be pulled in again, despite better knowledge)15:48
wyreqschulz, I feel that layer has dependencies that I don't need
wyrelike meta-qt515:54
wyreI don't need qt5 for a minimal image15:54
wyreLetoThe2nd, I'm reading the Rudolf Streif's book and watching your recommended playlist on youtbe15:55
wyrebut I've questions that's all ..15:55
qschulzwyre: worst case scenario, the layer is there but nothing from it is pulled15:55
qschulzalso nowhere does it say that qt is needed in that layer15:56
JaBen1@wyre: having the layer lying around is not an issue. especially when using kas which basically pulls all this dependencies automatically15:56
wyreqschulz, what about this?15:57
wyreJaBen1, what's 'kas'?15:57
LetoThe2ndwyre: rudis book is massively outdated, and my videos are really the bare bones minimum. they are more like geared towards total newbie students. using whateve $VENDORBSP strongly suggests that you are doing this for a living, and i apply a whole different set of expectations then. but anyways. i'm out for today. have fun eerybody.15:57
JaBen1@wyre just tells yocto to include the layer. this does not necessarily mean that stuff from there is used during your build.15:58
qschulzwyre: never seen base/conf directory before, only conflayer.conf matters15:58
wyreqschulz, so you think the layer is wrong designed?16:00
JPEWbase/conf/bblayers.conf is the "Example" bblayer.conf you can use in your own build conf/ directory (AFAICT)16:00
JaBen1@wyre: kas is basically a wrapper around bitbake projects (such as yocto): @LetoThe2nd made a good video on the topic:
JPEWwyre: You are correct though; that layer does depend on meta-qt5 (although they forgot to explicitly list in LAYERDEPENDS)16:01
wyreJaBen1, I think is better if I understand properly yocto before using a wrapper16:01
qschulzJPEW: vendor BSPS *le sigh*16:01
*** junland <junland!> has joined #yocto16:01
wyreJPEW, you mean here?
qschulzwyre: yes16:01
JPEWwyre: ya16:02
JPEWwyre: The problem is they've written *at least* one recipe that does "inherit qmake5" which will not parse if you don't have meta-qt516:02
wyreso you think could I extract from that BSP layer actually the minimal necessary to get a bootable image?16:02
tgamblinIs there a local.conf variable for specifying the amount of memory for runqemu to boot with?16:03
JaBen1@wyre: you can use kas basically like a normal bitbake project if you want (kas shell). but it removes the pain of manually having to prepare your build environment16:03
JPEWtgamblin: QB_MEM16:03
tgamblinJPEW: thanks!16:03
wyreJPEW, qschulz what do you think about freescale-layer and fsl-demos dependencies?16:04
wyreI know meta-freescale, meta-freescale-distro or meta-freescale-3rdparty but I dont know freescale-layer16:04
wyreand fsl-DEMOS?16:04
wyreI don't want any demo 😠16:04
JPEWwyre: Sure.... it depends on what you are going for.... if you just want something that boots, I would pull in everything you need as a first pass16:05
smurrayfreescale-layer == meta-freescale, that's it's layer name in its layer.conf16:05
qschulzwyre: don't know any of those and as I said sometime ago, I don't use vendor BSPs for avoiding being in your situation :)16:05
qschulzto avoid*16:05
JPEWwyre: Ya, It's a little confusing but the layer "name" it not always the same as what most people call it "meta-foo"16:06
qschulzJPEW: I think they managed already, but want to use warrior instead of pyro for some pytho dependency16:06
*** junland <junland!> has quit IRC16:06
*** jobroe <jobroe!> has quit IRC16:07
JPEWwyre: Ah, so you are past the "have it booting" stage and are at the "want to customize it" part?16:07
*** junland <junland!> has joined #yocto16:08
*** rcw <rcw!~rcwoolley@> has joined #yocto16:09
*** junland <junland!> has joined #yocto16:09
*** junland <junland!~junland@> has joined #yocto16:10
*** junland <junland!~junland@> has quit IRC16:11
*** dleppich <dleppich!~Thunderbi@> has quit IRC16:12
wyreJPEW, exactly16:12
*** junland <junland!> has joined #yocto16:12
JPEWwyre: Ok, well in that case, you have a few options:16:13
*** junland <junland!> has quit IRC16:14
JPEW1) use the BSP as-is with all the dependencies. You may want to audit what ends up in your final image, but well-written BSP layers shouldn't be inserting stuff you don't *actually* need, so you don't really need to worry about the layer dependencies so much16:14
*** junland <junland!> has joined #yocto16:15
JPEW(e.g. the BSP may depend on the freescale demo layer, but that doesn't mean it's going to throw a bunch of demo crap in your images)16:15
*** junland <junland!> has joined #yocto16:16
JPEW2) Tear down the BSP existing BSP to remove things you don't want (usually with some surgical BBMASK)16:16
JPEW3) Build up your own BSP using theirs as a starting point16:16
*** junland <junland!> has quit IRC16:16
*** junland <junland!> has joined #yocto16:17
JPEWwyre: That BSP in particular doesn't look very good. It's changing a lot of things that it shouldn't (busybox, init-ifupdown, etc.) so #1 isn't a good option16:18
smurrayI managed to bash meta-fsl-bsp-release into AGL at one point earlier this year, but decided it wasn't worth the hassle and threw that work away16:20
JPEWwyre: I suspect you don't *actually* need that much from the engicam BSP layer, so if it were me, I'd probably make my own BSP layer16:21
*** junland <junland!> has quit IRC16:21
*** jonasbits <jonasbits!~quassel@2001:2002:4e48:1aca:908e:1969:c028:2e1d> has quit IRC16:21
JPEWsmurray: Ya, we always just end up using meta-freescale16:22
*** junland <junland!> has joined #yocto16:22
wyreJPEW, thank you very much, you were so helpful 😊16:22
*** junland <junland!> has quit IRC16:23
JPEWwyre: np16:23
wyreI think is a good idea to use the current BSP as a starting point16:23
wyrebut what would you say are the most important parts in this BSP?16:23
wyreI mean, is there something that depends on the actual hardware?16:23
*** junland <junland!> has joined #yocto16:23
smurraywyre: you'll have to figure that out16:24
smurraywyre: if engicam have a machine conf for their board, look at what it configures16:24
JPEWwyre: It's hard to say *exactly* without digging and know your use case, but a BSP should be providing the stuff you need to get the hardware up (and not much else)... kernel, device drivers, that sort of thing16:24
wyreJPEW, so I guess freescale-layer is needed16:25
qschulzwyre: BSP stands for Board Package Support, so semantically a BSP layer should only contain things related to a particular hardware :)16:25
wyrethe point I think is in the demos and qt5 πŸ€”16:25
qschulzwyre: it's not because you have layers that you'll build what's in it16:25
JPEWwyre: Right. The good news there is that meta-freescale is higher quality, so I wouldn't worry too much about bringing that in16:25
wyreoh, yes, smurray I was actually using this one
qschulzwyre: see it as an possibly unused C header file. it's there, you need it because it's included, but maybe nothing uses it.16:26
qschulzwyre: well.. bad example as the header is still part of the build. meh. time to stop, you're in good company with JPEW and smurray anyway16:27
JPEWwyre: Right, so based on that machine.conf file, you *at a minimum* need a BSP layer that has: that machine.conf file, linux-engicam and u-boot-engicam16:27
*** w00die <w00die!~w00die@> has quit IRC16:34
*** junland <junland!> has quit IRC16:35
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto16:35
wyreJPEW, I guess I have to write a new recipe for an image also, is that right?16:36
*** w00die <w00die!~w00die@> has joined #yocto16:36
wyreI say this because I was using this as target when running bitbake16:37
wyreand what about the freescale-layer dependency? I guess could I maintain it and incude also meta-freescale, right?16:38
JPEWwyre: Yes, I would pull in meta-freescale as-is. You don't want to maintain your own copy of that layer16:39
*** stenscott <stenscott!c7f723c3@> has quit IRC16:40
JPEWwyre: Maintain your own fork of that layer16:40
JPEWArgh, keep hitting enter too soo: You don't want to maintain your own fork of meta-freescale16:40
wyreJPEW, of course, I'm cloning the repos :-)16:40
wyreJPEW, and regarding image? am I right?16:41
*** junland <junland!> has joined #yocto16:42
smurraywyre: you're going to need to make an image recipe for your own use anyway, seems reasonable to start with that one16:42
*** junland <junland!~junland@> has joined #yocto16:46
*** RPi_IMX6 <RPi_IMX6!> has joined #yocto16:49
zandreywyre: in addition to all valuable feedback you've received here, i would also suggest you start with "simple" setups, which does not involve heavy-lifting graphics and Qt layers on top.16:58
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has quit IRC17:00
zandreywe've already looked into this several days ago, and the engicam layer support is much to be desired. you can discard it for the moment, and start from a very basic setup, where you would just need to create your layer, bring the machine definition from engicam into it, and build one of core-images available to see if your HW is running fine.17:00
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has joined #yocto17:00
zandreyfor this you would require only meta-freescale; meta-freescale-distro can be taken later on when you would start to dig into graphics and Qt17:01
*** frsc <frsc!> has quit IRC17:01
*** armpit <armpit!~armpit@2601:202:4180:a5c0:55a3:5ef5:c2ab:7e5b> has quit IRC17:04
*** JaBen1 <JaBen1!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC17:06
*** willy_ <willy_!> has joined #yocto17:09
*** erakis <erakis!~erakis@> has joined #yocto17:11
*** RPi_IMX6 <RPi_IMX6!> has quit IRC17:13
*** JaBen1 <JaBen1!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto17:13
erakisHi, I'm trying to use a specific and old version of u-boot in meta-ti for a beaglebone black. I'm on the fido branch of Yocto. Is it suppose to work if I added theses lines to my local.conf file17:15
wyrezandrey, that's exactly what I want (remove all these heavy-liting graphics and layers on top)17:15
erakisPREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging"17:15
erakisPREFERRED_VERSION_linux-ti-staging = "3.14%"17:15
erakisPREFERRED_PROVIDER_u-boot = "u-boot-ti-staging"17:15
erakisPREFERRED_VERSION_u-boot = "2014.07"17:15
erakisOups, sorry I made a mistake. PREFERRED_VERSION_u-boot-ti-staging = "2014.07"17:17
qschulzerakis: why? the bbb is supported upstream so it makes little sense to actually require such old version17:19
qschulzsame for kernel17:20
*** jan <jan!> has joined #yocto17:22
*** jan is now known as Guest4990717:23
*** Guest49907 <Guest49907!> has quit IRC17:24
*** jansm <jansm!> has joined #yocto17:24
erakis@qschulz: You're right. But this is old configuration that we have and I'm not the author. I pull all new changes from the fido branch yesterday and this broke the u-boot mmc detection while booting ( The only way I found to fix it is to downgrade the version to 2014.07.17:25
*** zandrey <zandrey!~zandrey@> has quit IRC17:26
erakis@qschulz: And seriously, my knowledge of Yocto is quite limited :|17:26
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:a812:f255:469e:d33e> has quit IRC17:28
smurrayfido is so old that I suspect you're going to be on your own there17:28
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:29
erakis@qschulz: We are still using the kernel 3.14 !!!! I remember two years ago we tried to migrate to Krogoth branch with the help of Scott Ellis. We succeed but there was a really HIGH CPU USAGE when using serial port with the new kernel. We never been able to fix it. So we gave up :(17:31
erakissmurray: I know, this is what I often repeat to my supervisor ;)17:31
erakisAnyway, thank you guys ;)17:33
smurrayerakis: there's a beaglebone.conf in meta-ti, I'd recommend just using that as MACHINE if you need something the TI kernel has17:34
*** junland <junland!~junland@> has quit IRC17:34
*** B0ned1ger2 <B0ned1ger2!> has quit IRC17:35
*** B0ned1ger <B0ned1ger!> has joined #yocto17:35
*** fitzsim <fitzsim!> has quit IRC17:37
*** junland <junland!~junland@> has joined #yocto17:40
*** willy__ <willy__!> has joined #yocto17:41
erakissmurray: Honestly, Yocto we ended up understanding when playing in it, but for the device trees I never understood anything so it's quite penalizing when playing with the u-boot or the kernel and especially if we have specific hardware like an RGB screen or stuff plugged into the GPIOS. Which is our case.17:42
smurrayerakis: devicetree is its own beast, indeed17:43
*** willy_ <willy_!> has quit IRC17:45
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC17:47
*** vineela <vineela!~vtummala@> has joined #yocto17:48
*** fitzsim <fitzsim!> has joined #yocto17:53
khemRP:  did you see the latest set of patches I had to numpy ? any thougths ?17:54
*** Shikadi <Shikadi!> has joined #yocto17:55
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:57
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto17:57
*** davisr_ <davisr_!davisr@gateway/vpn/protonvpn/davisr> has quit IRC18:02
*** davisr_ <davisr_!davisr@gateway/vpn/protonvpn/davisr> has joined #yocto18:03
*** kpo_ <kpo_!> has quit IRC18:14
*** kpo_ <kpo_!> has joined #yocto18:14
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC18:15
*** junland <junland!~junland@> has quit IRC18:22
*** rcrudo <rcrudo!~rcrudo@2001:16b8:c214:e500:6bf:5a7f:3cd8:619e> has joined #yocto18:24
rcrudois it possible to install pypi whl packages with yocto thud. they seems to not work as the tar.gz ones18:25
*** junland <junland!~junland@> has joined #yocto18:25
*** junland <junland!~junland@> has quit IRC18:30
*** junland <junland!~junland@> has joined #yocto18:31
paulbarkerrcrudo: I don't expect that would work well. Python "wheels" are pre-built for particular platforms18:36
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has quit IRC18:41
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto18:43
mckoan|awaywyre: you can try our new Engicam setup here
*** yann <yann!~yann@> has quit IRC18:46
*** kaspter <kaspter!~Instantbi@> has quit IRC18:51
*** kaspter <kaspter!~Instantbi@> has joined #yocto18:51
*** willy__ <willy__!> has quit IRC18:58
*** willy__ <willy__!> has joined #yocto18:59
*** yann <yann!~yann@> has joined #yocto19:00
*** manuel1985 <manuel1985!> has joined #yocto19:03
*** manuel1985 <manuel1985!> has quit IRC19:05
wyrewow! mckoan|away that's pretty awesome! but ... why do you use repo?19:22
*** vineela <vineela!~vtummala@> has quit IRC19:24
*** agust1 <agust1!> has joined #yocto19:27
*** agust <agust!> has quit IRC19:27
*** lsandov1 <lsandov1!c8448bdf@> has joined #yocto19:30
lsandov1Hi man19:31
lsandov1I am back19:31
lsandov1The trustedfirmware CI work is just huge!19:31
lsandov1we (linaro) cannot just conclude it19:31
lsandov1anyway, now swatting the rest of the day19:32
*** creich_ <creich_!> has quit IRC19:37
*** creich <creich!> has joined #yocto19:40
*** gnac <gnac!> has joined #yocto19:45
*** rcoote <rcoote!> has joined #yocto19:57
*** vineela <vineela!~vtummala@> has joined #yocto20:08
*** jansm <jansm!> has quit IRC20:16
*** rcoote <rcoote!> has quit IRC20:17
*** mckoan|away is now known as mckoan20:18
mckoanwyre: I use repo because I love it20:18
wyremckoan, it's not similar to git?20:18
mckoanwyre: is a kind of git multi repo manager20:19
mckoangood night20:20
*** mckoan is now known as mckoan|away20:20
*** jrdn <jrdn!> has joined #yocto20:24
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC20:25
*** jrdn <jrdn!> has quit IRC20:55
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:02
*** pharaon2502 <pharaon2502!> has quit IRC21:03
*** mrc3_ <mrc3_!~mrc3@linaro/mrc3> has joined #yocto21:04
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto21:05
*** mrc3_ is now known as mrc321:07
*** maudat <maudat!> has joined #yocto21:08
*** erakis <erakis!~erakis@> has quit IRC21:10
*** matthewzmd <matthewzmd!~user@> has quit IRC21:17
*** matthewzmd <matthewzmd!~user@> has joined #yocto21:18
*** JaBen1 <JaBen1!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC21:19
*** matthewzmd <matthewzmd!~user@> has quit IRC21:23
*** matthewzmd <matthewzmd!~user@> has joined #yocto21:23
*** B0ned1ger <B0ned1ger!> has quit IRC21:36
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto21:36
*** roussinm <roussinm!> has quit IRC21:38
*** yann <yann!~yann@> has quit IRC21:57
*** camus <camus!~Instantbi@> has joined #yocto21:58
*** kaspter <kaspter!~Instantbi@> has quit IRC21:59
*** camus is now known as kaspter21:59
*** yann <yann!~yann@> has joined #yocto21:59
*** eduardas <eduardas!> has joined #yocto22:04
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:17
*** goliath <goliath!> has quit IRC22:19
*** grembeter <grembeter!c108287e@> has quit IRC22:20
*** beneth <beneth!> has left #yocto22:20
*** linums <linums!~linums@> has joined #yocto22:21
linumsCan anyone help how to change the renderer behind wayland22:22
linumsIt is uselessly laggy now :(22:22
JPEWlinums: You probably want to use the drm backend in weston.ini22:26
JPEWlinums: if your hardware supports it22:26
linumsSupposedly it is, I've seen the same machine used for better performance wayland run :D22:31
linumsWell, thanks, this solution sounds really easy :D22:31
*** camus <camus!~Instantbi@> has joined #yocto22:37
*** kaspter <kaspter!~Instantbi@> has quit IRC22:37
*** camus is now known as kaspter22:37
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC22:41
JPEWlinums: /etc/xdg/weston/weston.ini I think22:43
*** maudat <maudat!> has quit IRC22:44
linumsYeah, and I have the drm backend compiled, so soon I will know it =)22:48
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:ad4a:db0b:bf27:e23c> has quit IRC22:51
*** B0ned1ger <B0ned1ger!> has joined #yocto22:52
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:c938:be1b:ac1e:b8a2> has joined #yocto22:54
*** B0ned1ger2 <B0ned1ger2!> has quit IRC22:56
*** T_UNIX <T_UNIX!~T_UNIX@2a02:8071:b696:bd00:a66:4cbe:68f8:d8f> has quit IRC22:56
*** B0ned1ger <B0ned1ger!> has quit IRC22:56
*** JaBen1 <JaBen1!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto22:59
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:c938:be1b:ac1e:b8a2> has quit IRC23:01
*** lsandov1 <lsandov1!c8448bdf@> has left #yocto23:11
*** linums <linums!~linums@> has quit IRC23:25
*** linums <linums!> has joined #yocto23:25
*** rob_gries <rob_gries!> has quit IRC23:26
*** B0ned1ger <B0ned1ger!> has joined #yocto23:27
*** B0ned1ger <B0ned1ger!> has quit IRC23:32
*** davidinux <davidinux!~davidinux@> has quit IRC23:44

Generated by 2.17.2 by Marius Gedminas - find it at!