Monday, 2019-08-12

*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC00:28
*** armpit <armpit!~armpit@2601:202:4180:c33:e8c1:d902:42c1:9bf8> has quit IRC01:33
*** fatalhalt <fatalhalt!> has quit IRC01:41
*** fatalhalt <fatalhalt!> has joined #yocto01:44
*** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has joined #yocto01:45
*** fatalhalt <fatalhalt!> has quit IRC04:13
*** zkrx <zkrx!> has quit IRC05:32
*** AndersD <AndersD!> has joined #yocto05:49
*** goliath <goliath!> has joined #yocto06:03
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:14
*** kroon <kroon!~kroon@> has joined #yocto06:23
*** TobSnyder <TobSnyder!> has joined #yocto06:32
*** jmiehe <jmiehe!> has joined #yocto06:56
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC06:57
*** jeanba <jeanba!~jbl@> has joined #yocto06:58
*** jeanba <jeanba!~jbl@> has left #yocto06:58
*** Tamis <Tamis!504e0569@> has joined #yocto07:11
*** goliath <goliath!> has quit IRC07:15
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto07:34
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:56
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto07:59
*** goliath <goliath!~goliath@> has joined #yocto08:08
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:13
*** diego_r <diego_r!> has joined #yocto08:19
*** tprrt <tprrt!~tprrt@> has joined #yocto08:30
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC08:42
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC08:42
*** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has quit IRC08:42
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC08:42
*** OnkelUlla <OnkelUlla!> has quit IRC08:42
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:43
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:44
*** rsalveti <rsalveti!sid117878@gateway/web/> has quit IRC08:44
*** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has joined #yocto08:45
*** rsalveti <rsalveti!sid117878@gateway/web/> has joined #yocto08:46
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto08:47
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto08:47
*** OnkelUlla <OnkelUlla!> has joined #yocto08:47
*** Bunio_FH <Bunio_FH!> has joined #yocto08:58
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto09:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:35
*** AndersD_ <AndersD_!> has joined #yocto09:52
*** AndersD <AndersD!> has quit IRC09:55
yoctiNew news from stackoverflow: Should I specify the OELAYOUT_ABI variable in new yocto distro? <>10:14
*** winotu <winotu!> has joined #yocto10:19
winotuHi o/10:19
winotuI would like to know if I can get information from build log. What task where omitted and taken from sstate-cache or they were just omitted?10:21
winotuIn my case I have only logs without any debug information and I see that some task are not excuted and the number of following task which are executed increase byt the number of omitted tasks10:22
winotuI can't reproduce this behavior even using the same sstate-cache10:23
*** kukela_cd <kukela_cd!> has joined #yocto10:32
kukela_cdI have a quick question about opkg keyrings. ALL the keys i add to my keyring for use with opkg are marked as unknown. how do i change them to ultimate during the build process?10:33
*** kaspter <kaspter!~Instantbi@> has quit IRC10:34
*** winotu <winotu!> has quit IRC10:35
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:36
*** stephen <stephen!~stephen@unaffiliated/stephen> has joined #yocto10:36
stephenHello all. I'm having a hell of a run customizing an arm recipe just adding dahdi. It's called mlinux. Anyone familiar?10:37
jmiehesry for asking a C question (albeit a wicked one): I defined "FUN(TYPE)" as a generic to implement function "fun_##TYPE". gcc now seems to expand FUN(bool) to fun_bool *OR* fun__Bool randomly, which is at least annoying. Can I stop macro expansion in my macro?11:13
yoctiNew news from stackoverflow: Is there a way to install keys into the opkg-keyring during the yocto build process and have them marks as ultimate rather than unknown by gpg <>11:15
LetoThe2ndstephen: if you ask a little more precisely?11:20
stephenLetoThe2nd, certainly. I'm fairly new to yocto, so forgive if I skip important things, and, by all means, please point them out.11:22
LetoThe2ndstephen: start out with what you are trying to do, and where you get stuck :)11:22
stephenSo, I'm trying to build a cross compile environment to build a specific kernel module.11:23
LetoThe2ndstephen: this sounds like you are trying to manually crosscompile and such.11:24
stephenThe source for the driver is here:
stephenThe device I am trying to compile it for is an ARM device from Multitech11:25
stephenTheir linux is
LetoThe2ndstephen: your starting point should be then11:26
stephenmlinux is built using yocto.11:26
stephenYeah, the driver requires dahdi, which I realized openembedded supplies a recipe for, and is part of layer-telephony11:27
LetoThe2ndsounds about right.11:27
LetoThe2ndjmiehe: i'd guess this depends on included header before, and/or if its a c or c++ source file11:29
LetoThe2ndjmiehe: trigger word might be stdint.h/stdbool.h, but its pure guessowrk11:30
stephenNow I've gone down multiple paths to trying to accomplish this, at it's farthest I was on Ubuntu 16, and have tried using mlinux-5.0.0 and 4.1.9. I installed the mlinux toolchain, added a recipe to extend mlinux-base-image with dahdi-linux. At this point I have issues when I bitbake, as if mlinux is using an old version of python or something?11:30
LetoThe2ndstephen: first and foremore, the releases of all layers in use have to match.11:31
stephenAt one point I had the linux headers downloaded and I was having to go alter them (or create symlinks) to get the arm includes to be found11:31
LetoThe2ndstephen: i cannot tell on which poky/OE releases this mlinux is based, but common names would be pyro, rocko, sumo, thud, warrior11:31
stephenYeah, adding the layer seemed a bit to heavy, so I ended up trying to just include the recipe11:32
LetoThe2ndstephen: so if you add a layer, make sure its checked out branch matches the base system in use.11:32
stepheniy started with a K, one sec11:32
LetoThe2ndstephen: nope, thats outright wrong. layers are meant to be included as-is.11:32
stephenSo if I want dahdi, I need to include the entire layer that it's included in?11:33
stephenQuick aside: I do dual boot, but I have quicker access to WSL Ubuntu 16 right now. Any experience on success factors there?11:34
LetoThe2ndstephen: in a nutshell: don't do it.11:35
jmiehestephen: WSL is discouraged/unsupported/broken for yocto11:35
jmiehestephen: as I came to learn, the entire layer should be included and will be parsed, but only your dependencies will actually be built.11:35
LetoThe2ndthere are chances that WSL2 might be working some day, but as of today you need a proper linux box.11:35
*** diembed <diembed!> has joined #yocto11:37
jmieheLetoThe2nd: FUN(bool) will expand to FUN(_Bool) -- according to std (c99). Fine for var decls, but broken if I expect consistent function names. Why is bool even a macro and not a typedef?! Well … thinking about using _Bool directly now, even if my function is named fun__Bool then …11:38
LetoThe2ndjmiehe: don't ask me, i was just musing things that came to my mind.11:39
jmiehe… and stdbool is exactly the curse and the blessing here^^11:39
stephenok, second machine booted and VNC installed11:39
LetoThe2ndjmiehe: just use c++, you get consistent bool types AND even stricter typechecking ;-)11:40
LetoThe2ndstephen: and i just checked, meta-telephony does not seem to be in very good state11:41
* jmiehe would much rather directly migrate to Rust11:41
LetoThe2ndstephen: so you are certanly in for A LOT of fun.11:41
stephen:-/ Grrr11:41
stephenSo my main goal here is to build the driver for ARM. I don't need the env afterwards11:42
stephenAny thoughts on alternate paths?11:42
LetoThe2ndstephen: now that again is super shortsighted11:42
LetoThe2ndstephen: what happens if they ship driver source with a bugfix next year?11:42
stephenLetoThe2nd, publish or perish. I need the driver to upload to hardware we already have working, lacking this one usb device11:43
stephenI can fight the driver over the course of that year, and will happily contribute back11:43
LetoThe2ndyes, sure.11:44
LetoThe2ndin that case, try to just build in target11:44
stephenAnd that's not BS, this is hardware I'm going to need to support for a 5-10 year horizon.11:44
LetoThe2ndyes, sure.11:44
* stephen sulks and carves in blood "contribute" on his arm11:45
stephenTell me, how did you determine meta-telephony is in such a bad state?11:45
LetoThe2nddon't take it personal, but the combination of "support for 10 years" and "just need it to work once NOW" just does not exist.11:45
LetoThe2ndstephen: i looked at its branch list, and none matches a proper release.11:46
jmieheI've hacked a MWE for my problem if y'all interested
Crofton|workLetoThe2nd, they are supporting an older release in a branch11:46
Crofton|workthe m-t guys11:46
Crofton|workI might look at it if I get bored, would be nice to ahve it work for pi3 etc11:47
stephenActually, I'm going to have to create a build system that will pull this stuff from open source repos as a matter of security review. The build it now driver is for demo purpose11:47
LetoThe2ndCrofton|work: none to be found here:
LetoThe2ndCrofton|work: so thats what i based my assumption on11:47
LetoThe2ndstephen: like i said, follow the in-target building guide11:47
Crofton|workI'm not arguing with you11:47
LetoThe2ndstephen: should suffice for "getting it to work once." - and if not, go blame whomever gave that "mlinux" package to you.11:48
stephenNow, our final use case doesn't use asterisk, it uses FreeSwitch. As such, should I be heading this up under a different layer, or contributing to meta-telephony?11:48
*** berton <berton!~berton@> has joined #yocto11:48
LetoThe2ndCrofton|work: didn't take it as asguing, just pointing out where the information came from :)11:48
stephenMultitech. Part of me feels like they've left it in this state on purpose, but who knows11:49
Crofton|workstephen, we always suspect vendors of being evil :)11:49
* LetoThe2nd cheers.!11:49
* LetoThe2nd works for a HW vendor :)11:50
Crofton|worksome are better than others11:51
*** berton <berton!~berton@> has quit IRC11:51
LetoThe2ndthose are the black sheep11:51
Crofton|workstephen, the meta-telephony guys are in #osmocom11:52
Crofton|workI really should try merging the branch they use into master and building for a pi3 and see what happens11:52
*** berton <berton!~berton@> has joined #yocto11:53
*** weltling <weltling!> has left #yocto11:54
LetoThe2ndi would love so much to further procrastinate on getting my nodejs builds in shape but i guess i'll finally have to start. meh.11:54
Crofton|workI need to pack some borads for camp11:54
stephenWell now, if you ever need help in the nodejs arena, that's my standard bag11:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC11:55
LetoThe2ndstephen: give me a recipe for node8 with intl on armv7 :)11:55
LetoThe2nd(its really more of a build system problem, not exactly a node one)11:56
stephenIf you're not in a hurry, I'll have it ready before the end of the week11:56
stephenyou struggling with arm as well?11:56
Crofton|workand the leg11:56
LetoThe2ndno more than usual11:56
stephenthis is the arch the toolchain I'm installing claims to be: arm926ejste11:57
LetoThe2ndstephen: armv5, then.11:57
stephenWhich qemu machine supports that best?11:58
LetoThe2ndpretty much classic qemuarm that is11:58
LetoThe2ndat least until thud or so, we then moved forwards a bit.11:58
stephenI believe that's the version I was having to anchor on to keep mlinux compatible12:00
stephenMight even have to go back to Jethro12:00
LetoThe2ndstephen: not exactly current, but if it works, who cares.12:00
stephenFor reference, here's my starting point for building the mlinux env:
LetoThe2ndstephen: *sigh* that document mandates quite a bunch of bad practises.12:03
stephenAny chance you can point them out?12:03
stephenI'll document and write a better one.12:04
LetoThe2ndstephen: sure. 1) do not modify/add anything into a layer provided by anybody else12:04
LetoThe2ndstephen: 2) alsways bundle your stuff in a custom layer12:04
LetoThe2nd3) passing in root password through cli is also quite awkward, but if its their style....12:06
LetoThe2ndheh, thats also a good one: "If a recipe for your desired software is not available, you’ll need to write a custom recipe."12:07
Crofton|worklooks like they use submodules12:07
LetoThe2ndno link, no explanation on what this means.12:07
LetoThe2ndCrofton|work: *sigh* srsly?
stephenit probably means that their git clone should include switches to recurse into submodules12:08
stephenscrtch that12:11
LetoThe2ndmeta-multitech actually looks like a pretty generic bsp layer, little magic. ig uess they rather hide $STUFF in the mlinux download.12:12
Crofton|workI suppose I should do some real work12:14
yoctiNew news from stackoverflow: bitbake SRC_URI file:// <>12:15
kukela_cdMy problem I think is very simple. I would like to have opkg verify signatures before installing packages from my custom opkg repository. The issue I am having is that the keys I added to the opkg-keyrings yocto recipe are all marked as unknown on the target by gpg. They are all installed though. So when i attempt to install a package form my custo12:19
kukela_cdm repository, It fails because there are no trusted keys. I do not believe that this is a yocto bug, but I am running rocko.12:19
kukela_cdficently trusted public keys found.12:19
kukela_cdafter a little google foo and testing12:21
kukela_cdi think i need to stick something like this either in the opkg-keyring recipe or as a start up scripte gpg --list-keys --fingerprint --with-colons |\12:22
kukela_cdIs that a crazy idea ?12:22
stephenAnd see, grr... they supply their sdk, which essentially is a script that sources up a different script, yet the image build script uses oe-*. Along all this I ended up deciding I needed to source oe-blah first, then source their env12:24
stephenI have no idea if that is proper12:24
LetoThe2ndstephen: i only had a short peek but their sdk does at least not seem *too* weird.12:26
LetoThe2ndstephen: just documentation is kinda.. meh.12:26
stephenright now I've done 2 things: I have a shell with their sdk installed and sourced up12:28
stephen and I have a second which it bitbaking mlinux-factory-image from oe-init-build-env12:29
stephenif I can get into the image bitbaked, maybe I can opkg in what I need and build the driver?12:29
LetoThe2ndstephen: nope, thats not how it works12:30
stephenYeah, I figured as much12:30
stephenbut at least I'll know that their instructions at least get me into a virt of their device12:30
LetoThe2ndstephen: look at
stephenAs I understand it I need to create another bitbake target which includes the meta-telephony layer extending mlinux-factory-image12:31
LetoThe2ndstephen: that section pretty much exactly outlines what you need to do in order to be able to compile in-target12:31
LetoThe2ndas for doing it properly, you're right.12:32
stephenwhat are *.sdk images?12:32
stephenmlinux build as uboot and zImage12:32
stephenbecause the final result is flashed onto a piece of hardware12:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC12:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:33
LetoThe2ndthe key about an sdk image is that it brings toolchain, headers, etc.12:33
LetoThe2nd-> in-target compilation12:33
LetoThe2ndyou have to decide if you want to do the in-target way or the buildsystem way. mixing probably won't work12:35
stephenso if I have mlinux downloaded, how and where is the proper place to download the headers?12:36
LetoThe2ndif you do buildsystem, nowhere. it will take care of it for you.12:36
LetoThe2ndif you do in-target, nowhere. the buildsystem should do it for you and place them in the image12:36
LetoThe2ndif you want bitbake to take care of building stuff12:38
stephenSo essentially what I'm doing is source-ing into the provided env, then running bitbake. Aside from the layer/recipe edits, am I missing something?12:39
LetoThe2ndno, thats ok.12:40
LetoThe2ndbut you have to understand that this is an environment for doing bitbake tasks, and *NOT* for directly crosscompiling.12:40
stephenI understand that.12:40
stephenThe SDK is for cross compiles12:41
*** yacar_ <yacar_!~yacar@> has joined #yocto12:44
*** JaMa <JaMa!> has quit IRC13:15
*** yacar_ <yacar_!~yacar@> has quit IRC13:24
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:25
LetoThe2ndRP: do you have a quick pointer on how to disable uninative the most elegant way?13:27
RPLetoThe2nd: not sure there is a particularly neat way, wasn't really designed to be disabled easily once enabled13:30
*** marka <marka!~marka@> has joined #yocto13:30
RPLetoThe2nd: mkdir classes; touch uninative.bbclass ?13:30
*** yacar_ <yacar_!~yacar@> has joined #yocto13:30
LetoThe2ndRP: you mean for an existing build?13:30
RPLetoThe2nd: creating an empty class will work on any build13:30
stephenUgh, and here we go13:30
stephentry to build dadhi, it thinks h files are missing.13:31
LetoThe2ndRP: let me explain a little. i'm having a very specific kind of fun building node+icu for an older release, and uninative.conf seems to break things because it disables GLIBCXX13:31
RPLetoThe2nd: so alongside your conf directory which has local.conf, create a classes directory with a uninative.bbclass in it13:32
RP(an empty one)13:32
LetoThe2ndstephen: usually this is fixed by adding the provider of the desired headers to the DEPENDS13:32
LetoThe2ndRP: ok, let me give it a spin.13:32
RPLetoThe2nd: you're suggesting bitbake is like a game of chance?13:36
LetoThe2ndRP: how could i dare?!?13:36
* LetoThe2nd goes to find beer.13:37
RPLetoThe2nd: :)13:37
stephenSo, bitbaking mlinux-factory-image worked just fine13:38
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto13:44
LetoThe2ndRP: BTW, specific booze orders for lyon? ;-)13:45
kanavinRP: did you get quality afk time?13:52
RPkanavin: not at all, spent the weekend staring at runqueue as I was getting seriously worried about the release13:52
LetoThe2ndRP: would it also work if i place the empty class in my own layer? i think it should but i probably need a higher layer priority, right?13:52
RPLetoThe2nd: correct13:52
LetoThe2ndRP: ok, thanks13:53
RPkanavin: its kind of paid off as I was able to figure out the problem and I have some better code in testing locally13:54
kanavinRP: that's great to hear, but I was a bit concerned about your facebook post13:54
RPkanavin: I was feeling concerned too :(13:55
kanavinthat brought to mind one of my favorite british books13:56
*** TobSnyder <TobSnyder!> has quit IRC13:56
kanavinThis duty done, we refilled our glasses, lit our pipes, and resumed the discussion upon our state of health. What it was that was actually the matter with us, we none of us could be sure of; but the unanimous opinion was that it – whatever it was – had been brought on by overwork.13:56
kanavin“What we want is rest,” said Harris.13:56
kanavin“Rest and a complete change,” said George. “The overstrain upon our brains has produced a general depression throughout the system. Change of scene, and absence of the necessity for thought, will restore the mental equilibrium.”13:56
kanavinGeorge has a cousin, who is usually described in the charge-sheet as a medical student, so that he naturally has a somewhat family-physicianary way of putting things.13:56
*** georgem <georgem!~georgem@> has quit IRC13:56
kanavinI followed that advice in July (including the boat bit) with great results :)13:56
*** zkrx <zkrx!> has joined #yocto13:56
RPkanavin: good :)13:57
LetoThe2ndkanavin: this sums up as "get shitfaced when work is done", right?13:58
RPkanavin: the scary thing is I have some insight into those fatigue issues I've been struggling with. Not sure I like knowing what I now know though!13:58
kanavinRP: I thought you have some kind of poorly-understood chemistry issue in your body?13:59
RPkanavin: yes, I understand it a bit more now :/14:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC14:00
*** rcw <rcw!~rcw@> has joined #yocto14:00
kanavinLetoThe2nd, I was quoting
kanavinone of the first complete, original english books I read when I was in school14:01
LetoThe2ndkanavin: never heard of it. :) i was just summing it up into what i thought it shuold read :)14:01
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto14:02
*** kaspter <kaspter!~Instantbi@> has quit IRC14:08
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:08
*** AndersD_ <AndersD_!> has quit IRC14:09
*** goliath <goliath!~goliath@> has quit IRC14:23
*** vmeson <vmeson!> has quit IRC14:30
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC14:33
*** vmeson <vmeson!> has joined #yocto14:34
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto14:35
LetoThe2ndRP: ok. result: it works nicely when i comment out uninative in poky.conf. if i place classes/uninative.bbclass in my layer, layer prio 7, it seems to be ignored though14:38
armpitRP, I am seeing new build failures on warrior baseline. did you run a warrior build when I was on vacation?14:40
RPLetoThe2nd: what about alongside local.conf?14:40
RPLetoThe2nd: does your layer add to BBPATH? If so append or prepend?14:40
RParmpit: I thought maybe one. Which failures?14:41
LetoThe2ndRP: BBPATH .= ":${LAYERDIR}"14:41
RPLetoThe2nd: try prepending14:41
armpitqemuarm64-ptest, oe-selftest fadora14:41
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto14:41
RParmpit: fairly sure the ptest failure happened on the release build?14:41
armpitI just found warrior-next on july 29th with failures14:42
RParmpit: there is a small outside chance tgoodwin fixed a bug which was masking config issues too14:42
RParmpit: (in yocto-ab-helper)14:42
RP(or was it yocto-ab-2?)14:42
LetoThe2ndRP: =. breaks parsing because of other dependencies. :(14:42
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC14:43
armpitRP, just trying to figure out if I introduced new issue...14:44
RPLetoThe2nd: ok, second layer/sublayer which prepends?14:44
LetoThe2ndRP: and in build/conf next local.conf it also doesn't seem to be picked up. note: we are taking about krogoth :/14:44
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto14:44
RPLetoThe2nd: you want build/classes/uninative.bbclass14:44
RPLetoThe2nd: BBPATH hasn't changed behaviour in years14:45
LetoThe2ndRP: build/classes picks it up14:46
LetoThe2ndRP: *sigh* layer order as in
*** kroon <kroon!~kroon@> has quit IRC14:50
RPLetoThe2nd: layer ordering is a pain :(14:51
LetoThe2ndRP: yeah. reason this time was, for testing i added it through bitbake-layers. yet in CI another script takes care of it, which will place it at the top reproductibly. this is not exactly beautiful, but i think it suffices.14:52
* armpit hmm, arm64 is not listed as a tested host in 2.7.1 test results... is confused15:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC15:00
RParmpit: I think that failed on the 2.7.1 build15:01
armpitodd thing is thud passed the same build15:02
armpitin any case I opened bugs for the failures15:03
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto15:03
*** georgem <georgem!~georgem@> has joined #yocto15:04
*** pyrobby <pyrobby!> has joined #yocto15:05
pyrobbydoes bitbake have a way of returning a list of variables set in a particular bbclass? bb.parse.vars_from_file doesn't seem to do what I need15:09
armpitzeddii, thanks for merging the kfrags.. I forgot to include which kver they should have been against.15:12
*** yacar_ <yacar_!~yacar@> has quit IRC15:25
*** Bunio_FH <Bunio_FH!> has quit IRC15:31
*** goliath <goliath!> has joined #yocto15:35
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:42
*** yacar_ <yacar_!~yacar@> has joined #yocto15:50
*** tprrt <tprrt!~tprrt@> has quit IRC15:58
*** diembed <diembed!> has quit IRC16:04
*** jmiehe <jmiehe!> has quit IRC16:14
*** diego_r <diego_r!> has quit IRC16:20
*** yacar_ <yacar_!~yacar@> has quit IRC16:23
*** saraf <saraf!~a_saraf@> has joined #yocto16:28
*** stephen <stephen!~stephen@unaffiliated/stephen> has quit IRC16:54
*** JaMa <JaMa!> has joined #yocto17:04
*** dholland <dholland!> has quit IRC17:09
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC17:15
*** comptroller <comptroller!> has quit IRC17:23
*** vineela <vineela!vtummala@nat/intel/x-iwcobpxvhoqjzotl> has joined #yocto17:23
*** vineela <vineela!vtummala@nat/intel/x-iwcobpxvhoqjzotl> has quit IRC17:26
*** pyrobby <pyrobby!> has quit IRC17:27
*** comptroller <comptroller!> has joined #yocto17:35
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:49
*** rcw <rcw!~rcw@> has quit IRC17:58
*** rcw <rcw!~rcw@> has joined #yocto17:59
*** sgw <sgw!sgw@nat/intel/x-ibvxmgrvasscyspb> has quit IRC18:03
*** vineela <vineela!~vtummala@> has joined #yocto18:04
*** WillMiles <WillMiles!> has joined #yocto18:13
*** rcw <rcw!~rcw@> has quit IRC18:20
*** comptroller <comptroller!> has quit IRC18:23
*** comptroller <comptroller!> has joined #yocto18:35
*** stephen <stephen!~stephen@unaffiliated/stephen> has joined #yocto18:58
*** saraf <saraf!~a_saraf@> has quit IRC19:00
stephenCan anyone recommend an embedded hardware platform with good yocto support/well maintained which supports ethernet, serial, and modem connectivity?19:00
stephenBuilding on Multitech's past mistakes seems like a bad idea19:01
stephenosmocom, hmmm19:02
kayterinacompiling an opencv program I get "opencv2/opencv.hpp: No such file or directory" how to fix it in the recipe? I'm cross-compiling for rpi19:07
stephenkayterina, have you installed linux-libc-headers?19:11
stephenI'm guessing your target is arm or aarch?19:12
stephenIf so, be aware, source header linkage in that area of the code is a poorly maintained wasteland. In the end you may just have to find the file and correct the link19:13
*** tgraydon <tgraydon!tgraydon@nat/intel/x-leycmqxqywdmlprb> has joined #yocto19:17
*** rcw <rcw!~rcw@> has joined #yocto19:22
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto19:23
kayterinastephen: what file am I looking for to correct the link?19:34
stephenLook earlier on that line, or a couple lines before19:35
kayterinaIt is compiling ok in the host,do  linux-libc-headers need to be in the image too?19:35
stephenIt will be another h or hpp file which lists opencv.hpp as an include19:35
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC19:36
stephenkayterina, No clue, you should research what provides opencv.hpp19:36
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto19:36
stephenI run into this a lot when a directory has an asm-common directory but no asm/ directory19:36
stephenusually I just link the asm directory to the asm-common dir and try again19:36
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC19:45
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC19:47
*** rcw <rcw!~rcw@> has quit IRC19:47
*** berton <berton!~berton@> has quit IRC19:58
*** kroon <kroon!> has joined #yocto20:04
*** |aaron <|aaron!quasselcor@> has joined #yocto20:08
|aaronHi all. I'm trying to move DL_DIR to an NFS mounted directory. But when I do that, bitbake hangs forever the first time it tries to fetch files. Several 0 byte length .lock files are written to the NFS mount, but the actual files it's trying to fetch never make it there.20:10
|aaronTMPDIR is still on a regular disk20:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:13
*** kroon <kroon!> has quit IRC20:17
khem|aaron:which version of release are you on20:23
khemNFS is always finicky20:23
|aaronBitBake Build Tool Core version 1.40.020:24
*** WillMiles <WillMiles!> has quit IRC20:25
|aaronHeh that's an understatement re: NFS lol. I just ran an strace on bitbake and I'm seeing "futex(0x2005600, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1565641416, tv_nsec=986858000}, 0xffffffff) = -1 ETIMEDOUT (Connection timed out)" repeated over and over20:25
*** JPEW <JPEW!cc4da337@> has joined #yocto20:29
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:41
RPkhem: there? may need to be a bit careful with sstate from the hash equiv server :/20:54
|aaronOkay I figured it out, although not exactly clear why this was necessary. I ran bitbake with -D and saw that it was hanging at "Testing URL file://...". We had CONNECTIVITY_CHECK_URIS ?= "" set in our config, I set that var to empty instead and now it works20:58
|aaronHowever, now I'm having the same problem when i try to set SSTATE_DIR to the NFS mount. It hangs at "Testing URL file://..." even with that var set to emptuy20:59
JPEWRP: I wrote a quick fully async hash server you can try if you'20:59
JPEW*you're still having performance problems on the autobuilder:
JPEWThat should be able to handle connections until you run out of file descriptors :) . If it's still slow, it's probably sqlite21:00
*** comptroller <comptroller!> has quit IRC21:01
RPJPEW: perhaps you can help me understand where the bottleneck is.21:05
RPJPEW: I delete the unihash cache file, start a bitbake-hashserv, then run a "bitbake core-image-sato -kn".21:05
RPJPEW: what I then see is 6200 open connection to hashserv for over 30s21:06
RPJPEW: number of connections ~= number of tasks. I have to wonder why. I did already try and context manager around the urlopen()21:06
RPJPEW: definitely having performance problems. Last build was rather a mess :(21:08
JPEWIs the confusing part that there is are 6200 queries, or that each one is a new connection?21:08
*** rewitt <rewitt!~rewitt@> has quit IRC21:09
RPJPEW: there are 6200 *connections* open21:10
*** rewitt <rewitt!rewitt@nat/intel/x-lrrrfyhbatzmlhyu> has joined #yocto21:10
RPJPEW: so each one is a new connection21:10
*** comptroller <comptroller!> has joined #yocto21:12
JPEWRP: Are the connections stuck in TIME_WAIT state perhaps?21:13
RPJPEW: yes21:13
JPEWRP: I would expect to see a lot of connections in the TIME_WAIT state. Each TCP connection from the client is going to enter the TIME_WAIT state after the connection is closed... One solution would be to reuse a persistent connection to the server, but the stock urllib from python doesn't support that AFAIK21:17
JPEWRP: I  don't think that the connections in the TIME_WAIT are the source of the slow down.... they shouldn't really affect anything directly (although, it might strain the systems connection limit). I would be more worried to see a lot of active connections at once21:19
*** goliath <goliath!> has quit IRC21:19
*** agust <agust!> has quit IRC21:21
RPJPEW: I need to check what state things are sitting in21:24
*** kukela_cd <kukela_cd!> has quit IRC21:25
*** adelcast <adelcast!~adelcast@> has quit IRC21:29
JPEWRP: Really sorry, but I have to head home right now :(. I'll get back on IRC in the morning, or you can e-mail me with what you find. I'll look into trying to write some test programs to try and profile the hash equivalence server; there's probably some ways it can be made faster21:36
*** kaspter <kaspter!~Instantbi@> has quit IRC21:38
RPJPEW: no problem, I will need to sleep shortly too21:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto21:40
RPJPEW: I'm a bit fried after the other runqueue stuff tbh21:40
RPJPEW: I'm hoping there is something obvious/easy we're missing and can fix21:41
SaurRP: Btw, regarding my mail to the oe-core list regarding the delays with the current bitbake, don't take it as a criticism. I fully understand that correctness is your main concern at  the moment. Just take it as a data point from a live environment.21:45
RPSaur: you could see if master-next is any better21:54
RPSaur: clearly there is a problem and its not fit for purpose at the moment :(21:56
SaurRP: Now that you mention it, I think the first example in my mail (with the really extreme delays) were with the bitbake changes from master-next cherry-picked.21:56
RPSaur: so you're saying master-next made things worse? :/21:57
SaurHowever, I do not know if those changes were the cause or it was just a coincidence.21:57
SaurThat build was weird anyway, so probably best not to give it too much credit.21:57
RPSaur: I now have a dilemma. To try and fix the performance issue with runqueue itself, the one with the hash server, or the correctness issues the autobuilder threw up, or the day to day patch merging21:59
RPIts trying to do everything in parallel that is driving me crazy :/22:00
SaurRP: Wish I could help you. Unfortunately, when it comes to bitbake itself my knowledge is superficial at best.22:01
RPSaur: I think a good benchmark is "bitbake X -n" on a clean build directory fwiw22:01
RPSaur: it might be helpful to figure out where in master we regressed and if that "benchmark" does show it22:01
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:12
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:37
SaurRP: It seems to be commit 1f630fdf in bitbake that introduces the delays.22:46
JaMaRP: with bitbake master-next update from today, I'm now seeing: /bitbake/lib/bb/ ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('', 46449)> not sure if it's related to delays22:54
SaurAnyway, I'm off, but maybe that info can give you some idea where to look for the cause of the delays.22:55
khemRP:I was giving a go to hash things, I have disabled it for now22:59
khemRP: building full oe layers with bunch of bsp layers ends up with a world build with 45k tasks22:59
khemso speed is need22:59
khemfor now23:00
khemRP: ran -c testimage on rpi3 as well. Runs fairly well except few things, oeqa is very specific to messages coming from tested machines23:01
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:01
*** lexano__ <lexano__!> has quit IRC23:14
*** nick0001 <nick0001!> has joined #yocto23:18
*** lexano__ <lexano__!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto23:27
nick0001Hello. New to Yocto. I have added some layers to a build that was compiling correctly. And now I am getting   libccrypt.a relocation R_x86_64_PC32 against symbol 'ufc_foobar' cannot be sued when making a shared opbject recompile with -fPIC. i added -fPIC to compile and ld flags in the file (where the problem is reported) to no23:33
nick0001 success. I am now thinking to add that to where libcrypt is defined. But think that I am missing something bigger. Can anyone offer any help? Thank you in advance.23:33
khemyou should check the newly added layers for setting global config metadata23:50
khemsome layers are notorious23:50
*** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has quit IRC23:58
*** tgraydon <tgraydon!tgraydon@nat/intel/x-leycmqxqywdmlprb> has quit IRC23:58
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto23:58

Generated by 2.11.0 by Marius Gedminas - find it at!