| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-rgxesdimzqenobff> has quit IRC | 00:28 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:e8c1:d902:42c1:9bf8> has quit IRC | 01:33 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 01:41 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto | 01:44 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has joined #yocto | 01:45 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 04:13 | |
| *** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has quit IRC | 05:32 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:49 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:03 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 06:14 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:23 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:32 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:56 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 06:57 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has joined #yocto | 06:58 | |
| *** jeanba <jeanba!~jbl@77.243.63.34> has left #yocto | 06:58 | |
| *** Tamis <Tamis!504e0569@80.78.5.105> has joined #yocto | 07:11 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:15 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto | 07:34 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:56 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qaewyqbbbpvkuhgc> has joined #yocto | 07:59 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:08 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 08:13 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:19 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 08:30 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qaewyqbbbpvkuhgc> has quit IRC | 08:42 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 08:42 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has quit IRC | 08:42 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 08:42 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 08:42 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-edipqulfondatggr> has joined #yocto | 08:43 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 08:44 | |
| *** rsalveti <rsalveti!sid117878@gateway/web/irccloud.com/x-knaotsnjmsavobfd> has quit IRC | 08:44 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:4433:1c24:7cd8:6011> has joined #yocto | 08:45 | |
| *** rsalveti <rsalveti!sid117878@gateway/web/irccloud.com/x-zpvgyhoaxlddshon> has joined #yocto | 08:46 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto | 08:47 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 08:47 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 08:47 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:58 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 09:15 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:31 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:35 | |
| *** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 09:52 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 09:55 | |
| yocti | New news from stackoverflow: Should I specify the OELAYOUT_ABI variable in new yocto distro? <https://stackoverflow.com/questions/57458977/should-i-specify-the-oelayout-abi-variable-in-new-yocto-distro> | 10:14 |
|---|---|---|
| *** winotu <winotu!4e0b08f9@78-11-8-249.static.ip.netia.com.pl> has joined #yocto | 10:19 | |
| winotu | Hi o/ | 10:19 |
| winotu | I 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 |
| winotu | In 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 tasks | 10:22 |
| winotu | I can't reproduce this behavior even using the same sstate-cache | 10:23 |
| *** kukela_cd <kukela_cd!ae63deca@174-099-222-202.biz.spectrum.com> has joined #yocto | 10:32 | |
| kukela_cd | I 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@115.230.123.98> has quit IRC | 10:34 | |
| *** winotu <winotu!4e0b08f9@78-11-8-249.static.ip.netia.com.pl> has quit IRC | 10:35 | |
| *** kaspter <kaspter!~Instantbi@183.128.238.14> has joined #yocto | 10:36 | |
| *** stephen <stephen!~stephen@unaffiliated/stephen> has joined #yocto | 10:36 | |
| stephen | Hello all. I'm having a hell of a run customizing an arm recipe just adding dahdi. It's called mlinux. Anyone familiar? | 10:37 |
| jmiehe | sry 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 |
| yocti | New 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 <https://stackoverflow.com/questions/57459812/is-there-a-way-to-install-keys-into-the-opkg-keyring-during-the-yocto-build-proc> | 11:15 |
| LetoThe2nd | stephen: if you ask a little more precisely? | 11:20 |
| stephen | LetoThe2nd, certainly. I'm fairly new to yocto, so forgive if I skip important things, and, by all means, please point them out. | 11:22 |
| LetoThe2nd | stephen: start out with what you are trying to do, and where you get stuck :) | 11:22 |
| stephen | So, I'm trying to build a cross compile environment to build a specific kernel module. | 11:23 |
| LetoThe2nd | stephen: this sounds like you are trying to manually crosscompile and such. | 11:24 |
| stephen | The source for the driver is here: http://amfeltec.com/drivers/USB-FXO/ | 11:24 |
| stephen | The device I am trying to compile it for is an ARM device from Multitech | 11:25 |
| stephen | Their linux is http://www.multitech.net/developer/software/mlinux/ | 11:26 |
| LetoThe2nd | stephen: your starting point should be https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules then | 11:26 |
| stephen | mlinux is built using yocto. | 11:26 |
| stephen | Yeah, the driver requires dahdi, which I realized openembedded supplies a recipe for, and is part of layer-telephony | 11:27 |
| LetoThe2nd | sounds about right. | 11:27 |
| LetoThe2nd | jmiehe: i'd guess this depends on included header before, and/or if its a c or c++ source file | 11:29 |
| LetoThe2nd | jmiehe: trigger word might be stdint.h/stdbool.h, but its pure guessowrk | 11:30 |
| stephen | Now 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 |
| LetoThe2nd | stephen: first and foremore, the releases of all layers in use have to match. | 11:31 |
| stephen | At 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 found | 11:31 |
| LetoThe2nd | stephen: i cannot tell on which poky/OE releases this mlinux is based, but common names would be pyro, rocko, sumo, thud, warrior | 11:31 |
| stephen | Yeah, adding the layer seemed a bit to heavy, so I ended up trying to just include the recipe | 11:32 |
| LetoThe2nd | stephen: so if you add a layer, make sure its checked out branch matches the base system in use. | 11:32 |
| stephen | iy started with a K, one sec | 11:32 |
| LetoThe2nd | stephen: nope, thats outright wrong. layers are meant to be included as-is. | 11:32 |
| stephen | So if I want dahdi, I need to include the entire layer that it's included in? | 11:33 |
| LetoThe2nd | yes. | 11:33 |
| stephen | Quick aside: I do dual boot, but I have quicker access to WSL Ubuntu 16 right now. Any experience on success factors there? | 11:34 |
| LetoThe2nd | stephen: in a nutshell: don't do it. | 11:35 |
| jmiehe | stephen: WSL is discouraged/unsupported/broken for yocto | 11:35 |
| jmiehe | stephen: 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 |
| LetoThe2nd | there are chances that WSL2 might be working some day, but as of today you need a proper linux box. | 11:35 |
| *** diembed <diembed!~diembed@34.16-66-87.adsl-static.isp.belgacom.be> has joined #yocto | 11:37 | |
| jmiehe | LetoThe2nd: 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 |
| LetoThe2nd | jmiehe: 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 |
| stephen | ok, second machine booted and VNC installed | 11:39 |
| LetoThe2nd | jmiehe: just use c++, you get consistent bool types AND even stricter typechecking ;-) | 11:40 |
| LetoThe2nd | stephen: and i just checked, meta-telephony does not seem to be in very good state | 11:41 |
| * jmiehe would much rather directly migrate to Rust | 11:41 | |
| LetoThe2nd | stephen: so you are certanly in for A LOT of fun. | 11:41 |
| stephen | :-/ Grrr | 11:41 |
| stephen | So my main goal here is to build the driver for ARM. I don't need the env afterwards | 11:42 |
| stephen | Any thoughts on alternate paths? | 11:42 |
| LetoThe2nd | stephen: now that again is super shortsighted | 11:42 |
| LetoThe2nd | stephen: what happens if they ship driver source with a bugfix next year? | 11:42 |
| stephen | LetoThe2nd, publish or perish. I need the driver to upload to hardware we already have working, lacking this one usb device | 11:43 |
| stephen | I can fight the driver over the course of that year, and will happily contribute back | 11:43 |
| LetoThe2nd | yes, sure. | 11:44 |
| LetoThe2nd | in that case, try https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#building-out-of-tree-modules-on-the-target to just build in target | 11:44 |
| stephen | And that's not BS, this is hardware I'm going to need to support for a 5-10 year horizon. | 11:44 |
| LetoThe2nd | yes, sure. | 11:44 |
| stephen | lol | 11:44 |
| * stephen sulks and carves in blood "contribute" on his arm | 11:45 | |
| stephen | Tell me, how did you determine meta-telephony is in such a bad state? | 11:45 |
| LetoThe2nd | don'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 |
| LetoThe2nd | stephen: i looked at its branch list, and none matches a proper release. | 11:46 |
| jmiehe | I've hacked a MWE for my problem if y'all interested https://repl.it/repls/UnkemptPrestigiousLevel | 11:46 |
| Crofton|work | LetoThe2nd, they are supporting an older release in a branch | 11:46 |
| Crofton|work | the m-t guys | 11:46 |
| Crofton|work | I might look at it if I get bored, would be nice to ahve it work for pi3 etc | 11:47 |
| stephen | Actually, 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 purpose | 11:47 |
| LetoThe2nd | Crofton|work: none to be found here: http://git.osmocom.org/meta-telephony/refs/ | 11:47 |
| LetoThe2nd | Crofton|work: so thats what i based my assumption on | 11:47 |
| Crofton|work | http://git.osmocom.org/meta-telephony/log/?h=201705 | 11:47 |
| LetoThe2nd | stephen: like i said, follow the in-target building guide | 11:47 |
| Crofton|work | I'm not arguing with you | 11:47 |
| LetoThe2nd | stephen: should suffice for "getting it to work once." - and if not, go blame whomever gave that "mlinux" package to you. | 11:48 |
| stephen | Now, 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@181.220.88.207> has joined #yocto | 11:48 | |
| LetoThe2nd | Crofton|work: didn't take it as asguing, just pointing out where the information came from :) | 11:48 |
| stephen | Multitech. Part of me feels like they've left it in this state on purpose, but who knows | 11:49 |
| Crofton|work | stephen, we always suspect vendors of being evil :) | 11:49 |
| * LetoThe2nd cheers.! | 11:49 | |
| * LetoThe2nd works for a HW vendor :) | 11:50 | |
| Crofton|work | :) | 11:51 |
| Crofton|work | some are better than others | 11:51 |
| *** berton <berton!~berton@181.220.88.207> has quit IRC | 11:51 | |
| LetoThe2nd | those are the black sheep | 11:51 |
| Crofton|work | stephen, the meta-telephony guys are in #osmocom | 11:52 |
| Crofton|work | I really should try merging the branch they use into master and building for a pi3 and see what happens | 11:52 |
| *** berton <berton!~berton@181.220.88.207> has joined #yocto | 11:53 | |
| *** weltling <weltling!~toll@klapt.com> has left #yocto | 11:54 | |
| LetoThe2nd | i 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|work | lol | 11:54 |
| Crofton|work | yeah | 11:54 |
| Crofton|work | I need to pack some borads for camp | 11:54 |
| stephen | Well now, if you ever need help in the nodejs arena, that's my standard bag | 11:54 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 11:55 | |
| LetoThe2nd | stephen: 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 |
| stephen | If you're not in a hurry, I'll have it ready before the end of the week | 11:56 |
| stephen | you struggling with arm as well? | 11:56 |
| Crofton|work | and the leg | 11:56 |
| LetoThe2nd | no more than usual | 11:56 |
| stephen | \o | 11:56 |
| stephen | this is the arch the toolchain I'm installing claims to be: arm926ejste | 11:57 |
| LetoThe2nd | stephen: armv5, then. | 11:57 |
| stephen | Which qemu machine supports that best? | 11:58 |
| LetoThe2nd | pretty much classic qemuarm that is | 11:58 |
| LetoThe2nd | at least until thud or so, we then moved forwards a bit. | 11:58 |
| stephen | Krogoth | 11:59 |
| stephen | I believe that's the version I was having to anchor on to keep mlinux compatible | 12:00 |
| stephen | Might even have to go back to Jethro | 12:00 |
| LetoThe2nd | stephen: not exactly current, but if it works, who cares. | 12:00 |
| stephen | For reference, here's my starting point for building the mlinux env: https://www.multitech.net/developer/software/mlinux/mlinux-building-images/building-a-custom-linux-image/ | 12:02 |
| LetoThe2nd | stephen: *sigh* that document mandates quite a bunch of bad practises. | 12:03 |
| stephen | Any chance you can point them out? | 12:03 |
| stephen | I'll document and write a better one. | 12:04 |
| LetoThe2nd | stephen: sure. 1) do not modify/add anything into a layer provided by anybody else | 12:04 |
| LetoThe2nd | stephen: 2) alsways bundle your stuff in a custom layer | 12:04 |
| LetoThe2nd | 3) passing in root password through cli is also quite awkward, but if its their style.... | 12:06 |
| Crofton|work | http://git.multitech.net/cgi-bin/cgit.cgi/meta-multitech.git/ | 12:07 |
| LetoThe2nd | heh, 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|work | looks like they use submodules | 12:07 |
| LetoThe2nd | no link, no explanation on what this means. | 12:07 |
| LetoThe2nd | Crofton|work: *sigh* srsly? http://git.multitech.net/cgi-bin/cgit.cgi/meta-multitech.git/tree/README?id=5.0.0 | 12:08 |
| stephen | it probably means that their git clone should include switches to recurse into submodules | 12:08 |
| stephen | scrtch that | 12:11 |
| LetoThe2nd | meta-multitech actually looks like a pretty generic bsp layer, little magic. ig uess they rather hide $STUFF in the mlinux download. | 12:12 |
| Crofton|work | I suppose I should do some real work | 12:14 |
| yocti | New news from stackoverflow: bitbake SRC_URI file:// <https://stackoverflow.com/questions/27815990/bitbake-src-uri-file> | 12:15 |
| kukela_cd | My 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 custo | 12:19 |
| kukela_cd | m 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_cd | ficently trusted public keys found. | 12:19 |
| kukela_cd | after a little google foo and testing | 12:21 |
| kukela_cd | i 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_cd | Is that a crazy idea ? | 12:22 |
| stephen | And 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 env | 12:24 |
| stephen | I have no idea if that is proper | 12:24 |
| LetoThe2nd | stephen: i only had a short peek but their sdk does at least not seem *too* weird. | 12:26 |
| LetoThe2nd | stephen: just documentation is kinda.. meh. | 12:26 |
| stephen | right now I've done 2 things: I have a shell with their sdk installed and sourced up | 12:28 |
| stephen | and I have a second which it bitbaking mlinux-factory-image from oe-init-build-env | 12:29 |
| stephen | if I can get into the image bitbaked, maybe I can opkg in what I need and build the driver? | 12:29 |
| LetoThe2nd | stephen: nope, thats not how it works | 12:30 |
| stephen | Yeah, I figured as much | 12:30 |
| stephen | but at least I'll know that their instructions at least get me into a virt of their device | 12:30 |
| LetoThe2nd | stephen: look at https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#building-out-of-tree-modules-on-the-target | 12:31 |
| stephen | As I understand it I need to create another bitbake target which includes the meta-telephony layer extending mlinux-factory-image | 12:31 |
| LetoThe2nd | stephen: that section pretty much exactly outlines what you need to do in order to be able to compile in-target | 12:31 |
| LetoThe2nd | as for doing it properly, you're right. | 12:32 |
| stephen | what are *.sdk images? | 12:32 |
| stephen | mlinux build as uboot and zImage | 12:32 |
| stephen | because the final result is flashed onto a piece of hardware | 12:33 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 12:33 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 12:33 | |
| LetoThe2nd | the key about an sdk image is that it brings toolchain, headers, etc. | 12:33 |
| LetoThe2nd | -> in-target compilation | 12:33 |
| LetoThe2nd | you have to decide if you want to do the in-target way or the buildsystem way. mixing probably won't work | 12:35 |
| stephen | so if I have mlinux downloaded, how and where is the proper place to download the headers? | 12:36 |
| LetoThe2nd | if you do buildsystem, nowhere. it will take care of it for you. | 12:36 |
| LetoThe2nd | if you do in-target, nowhere. the buildsystem should do it for you and place them in the image | 12:36 |
| stephen | buildsystem? | 12:37 |
| LetoThe2nd | if you want bitbake to take care of building stuff | 12:38 |
| stephen | So 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 |
| LetoThe2nd | no, thats ok. | 12:40 |
| LetoThe2nd | but you have to understand that this is an environment for doing bitbake tasks, and *NOT* for directly crosscompiling. | 12:40 |
| stephen | I understand that. | 12:40 |
| stephen | The SDK is for cross compiles | 12:41 |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has joined #yocto | 12:44 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 13:15 | |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has quit IRC | 13:24 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:25 | |
| LetoThe2nd | RP: do you have a quick pointer on how to disable uninative the most elegant way? | 13:27 |
| RP | LetoThe2nd: not sure there is a particularly neat way, wasn't really designed to be disabled easily once enabled | 13:30 |
| *** marka <marka!~marka@184.175.21.100> has joined #yocto | 13:30 | |
| RP | LetoThe2nd: mkdir classes; touch uninative.bbclass ? | 13:30 |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has joined #yocto | 13:30 | |
| LetoThe2nd | RP: you mean for an existing build? | 13:30 |
| RP | LetoThe2nd: creating an empty class will work on any build | 13:30 |
| stephen | Ugh, and here we go | 13:30 |
| stephen | try to build dadhi, it thinks h files are missing. | 13:31 |
| LetoThe2nd | RP: 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 GLIBCXX | 13:31 |
| RP | LetoThe2nd: so alongside your conf directory which has local.conf, create a classes directory with a uninative.bbclass in it | 13:32 |
| RP | (an empty one) | 13:32 |
| LetoThe2nd | stephen: usually this is fixed by adding the provider of the desired headers to the DEPENDS | 13:32 |
| LetoThe2nd | RP: ok, let me give it a spin. | 13:32 |
| RP | LetoThe2nd: you're suggesting bitbake is like a game of chance? | 13:36 |
| LetoThe2nd | RP: how could i dare?!? | 13:36 |
| * LetoThe2nd goes to find beer. | 13:37 | |
| RP | LetoThe2nd: :) | 13:37 |
| stephen | So, bitbaking mlinux-factory-image worked just fine | 13:38 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 13:44 | |
| LetoThe2nd | RP: BTW, specific booze orders for lyon? ;-) | 13:45 |
| kanavin | RP: did you get quality afk time? | 13:52 |
| RP | kanavin: not at all, spent the weekend staring at runqueue as I was getting seriously worried about the release | 13:52 |
| LetoThe2nd | RP: 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 |
| RP | LetoThe2nd: correct | 13:52 |
| LetoThe2nd | RP: ok, thanks | 13:53 |
| RP | kanavin: its kind of paid off as I was able to figure out the problem and I have some better code in testing locally | 13:54 |
| kanavin | RP: that's great to hear, but I was a bit concerned about your facebook post | 13:54 |
| RP | kanavin: I was feeling concerned too :( | 13:55 |
| kanavin | that brought to mind one of my favorite british books | 13:56 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 13:56 | |
| kanavin | This 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 |
| kanavin | George 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@216.21.169.52> has quit IRC | 13:56 | |
| kanavin | I followed that advice in July (including the boat bit) with great results :) | 13:56 |
| *** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has joined #yocto | 13:56 | |
| RP | kanavin: good :) | 13:57 |
| LetoThe2nd | kanavin: this sums up as "get shitfaced when work is done", right? | 13:58 |
| RP | kanavin: 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 |
| kanavin | RP: I thought you have some kind of poorly-understood chemistry issue in your body? | 13:59 |
| RP | kanavin: yes, I understand it a bit more now :/ | 14:00 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 14:00 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 14:00 | |
| kanavin | LetoThe2nd, I was quoting http://www.authorama.com/three-men-in-a-boat-1.html | 14:00 |
| kanavin | one of the first complete, original english books I read when I was in school | 14:01 |
| LetoThe2nd | kanavin: 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 #yocto | 14:02 | |
| *** kaspter <kaspter!~Instantbi@183.128.238.14> has quit IRC | 14:08 | |
| *** kaspter <kaspter!~Instantbi@183.128.238.14> has joined #yocto | 14:08 | |
| *** AndersD_ <AndersD_!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:09 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:23 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 14:30 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 14:33 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 14:34 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto | 14:35 | |
| LetoThe2nd | RP: 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 though | 14:38 |
| armpit | RP, I am seeing new build failures on warrior baseline. did you run a warrior build when I was on vacation? | 14:40 |
| RP | LetoThe2nd: what about alongside local.conf? | 14:40 |
| RP | LetoThe2nd: does your layer add to BBPATH? If so append or prepend? | 14:40 |
| RP | armpit: I thought maybe one. Which failures? | 14:41 |
| LetoThe2nd | RP: BBPATH .= ":${LAYERDIR}" | 14:41 |
| RP | LetoThe2nd: try prepending | 14:41 |
| armpit | qemuarm64-ptest, oe-selftest fadora | 14:41 |
| *** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-uxmdfjyvjbweskmt> has joined #yocto | 14:41 | |
| RP | armpit: fairly sure the ptest failure happened on the release build? | 14:41 |
| armpit | I just found warrior-next on july 29th with failures | 14:42 |
| RP | armpit: there is a small outside chance tgoodwin fixed a bug which was masking config issues too | 14:42 |
| RP | armpit: (in yocto-ab-helper) | 14:42 |
| RP | (or was it yocto-ab-2?) | 14:42 |
| LetoThe2nd | RP: =. breaks parsing because of other dependencies. :( | 14:42 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 14:43 | |
| armpit | RP, just trying to figure out if I introduced new issue... | 14:44 |
| RP | LetoThe2nd: ok, second layer/sublayer which prepends? | 14:44 |
| LetoThe2nd | RP: 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 #yocto | 14:44 | |
| RP | LetoThe2nd: you want build/classes/uninative.bbclass | 14:44 |
| RP | LetoThe2nd: BBPATH hasn't changed behaviour in years | 14:45 |
| LetoThe2nd | RP: build/classes picks it up | 14:46 |
| LetoThe2nd | RP: *sigh* layer order as in https://stackoverflow.com/questions/51002891/overwriting-yocto-classes-through-meta-layer | 14:50 |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:50 | |
| RP | LetoThe2nd: layer ordering is a pain :( | 14:51 |
| LetoThe2nd | RP: 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 confused | 15:00 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 15:00 | |
| RP | armpit: I think that failed on the 2.7.1 build | 15:01 |
| armpit | odd thing is thud passed the same build | 15:02 |
| armpit | in any case I opened bugs for the failures | 15:03 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has joined #yocto | 15:03 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 15:04 | |
| *** pyrobby <pyrobby!5005db08@cpc108965-cmbg20-2-0-cust775.5-4.cable.virginm.net> has joined #yocto | 15:05 | |
| pyrobby | hi | 15:05 |
| pyrobby | does 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 need | 15:09 |
| armpit | zeddii, thanks for merging the kfrags.. I forgot to include which kver they should have been against. | 15:12 |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has quit IRC | 15:25 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:31 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 15:35 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 15:42 | |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has joined #yocto | 15:50 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 15:58 | |
| *** diembed <diembed!~diembed@34.16-66-87.adsl-static.isp.belgacom.be> has quit IRC | 16:04 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:14 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:20 | |
| *** yacar_ <yacar_!~yacar@80.215.244.172> has quit IRC | 16:23 | |
| *** saraf <saraf!~a_saraf@45.127.45.104> has joined #yocto | 16:28 | |
| *** stephen <stephen!~stephen@unaffiliated/stephen> has quit IRC | 16:54 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 17:04 | |
| *** dholland <dholland!~quassel@vpn.pelagicore.de> has quit IRC | 17:09 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:b7a3> has quit IRC | 17:15 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 17:23 | |
| *** vineela <vineela!vtummala@nat/intel/x-iwcobpxvhoqjzotl> has joined #yocto | 17:23 | |
| *** vineela <vineela!vtummala@nat/intel/x-iwcobpxvhoqjzotl> has quit IRC | 17:26 | |
| *** pyrobby <pyrobby!5005db08@cpc108965-cmbg20-2-0-cust775.5-4.cable.virginm.net> has quit IRC | 17:27 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 17:35 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-edipqulfondatggr> has quit IRC | 17:49 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 17:58 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 17:59 | |
| *** sgw <sgw!sgw@nat/intel/x-ibvxmgrvasscyspb> has quit IRC | 18:03 | |
| *** vineela <vineela!~vtummala@134.134.139.73> has joined #yocto | 18:04 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 18:13 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 18:20 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 18:23 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 18:35 | |
| *** stephen <stephen!~stephen@unaffiliated/stephen> has joined #yocto | 18:58 | |
| *** saraf <saraf!~a_saraf@45.127.45.104> has quit IRC | 19:00 | |
| stephen | Can anyone recommend an embedded hardware platform with good yocto support/well maintained which supports ethernet, serial, and modem connectivity? | 19:00 |
| stephen | Building on Multitech's past mistakes seems like a bad idea | 19:01 |
| stephen | osmocom, hmmm | 19:02 |
| kayterina | compiling 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 rpi | 19:07 |
| stephen | kayterina, have you installed linux-libc-headers? | 19:11 |
| stephen | I'm guessing your target is arm or aarch? | 19:12 |
| stephen | If 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 link | 19:13 |
| *** tgraydon <tgraydon!tgraydon@nat/intel/x-leycmqxqywdmlprb> has joined #yocto | 19:17 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:22 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.251.77> has joined #yocto | 19:23 | |
| kayterina | stephen: what file am I looking for to correct the link? | 19:34 |
| stephen | Look earlier on that line, or a couple lines before | 19:35 |
| kayterina | It is compiling ok in the host,do linux-libc-headers need to be in the image too? | 19:35 |
| stephen | It will be another h or hpp file which lists opencv.hpp as an include | 19:35 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.251.77> has quit IRC | 19:36 | |
| stephen | kayterina, No clue, you should research what provides opencv.hpp | 19:36 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.251.77> has joined #yocto | 19:36 | |
| stephen | I run into this a lot when a directory has an asm-common directory but no asm/ directory | 19:36 |
| stephen | usually I just link the asm directory to the asm-common dir and try again | 19:36 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.251.77> has quit IRC | 19:45 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 19:47 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:47 | |
| *** berton <berton!~berton@181.220.88.207> has quit IRC | 19:58 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 20:04 | |
| *** |aaron <|aaron!quasselcor@192.95.25.101> has joined #yocto | 20:08 | |
| |aaron | Hi 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 |
| |aaron | TMPDIR is still on a regular disk | 20:10 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:13 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 20:17 | |
| khem | |aaron:which version of release are you on | 20:23 |
| khem | NFS is always finicky | 20:23 |
| |aaron | BitBake Build Tool Core version 1.40.0 | 20:24 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:25 | |
| |aaron | Heh 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 over | 20:25 |
| *** JPEW <JPEW!cc4da337@204.77.163.55> has joined #yocto | 20:29 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:41 | |
| RP | khem: there? may need to be a bit careful with sstate from the hash equiv server :/ | 20:54 |
| |aaron | Okay 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 ?= "http://builds.ourdomain.com:88/mirror/sources/" set in our config, I set that var to empty instead and now it works | 20:58 |
| |aaron | However, 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 emptuy | 20:59 |
| JPEW | RP: 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: https://github.com/JPEWdev/aiohashserver | 21:00 |
| JPEW | That should be able to handle connections until you run out of file descriptors :) . If it's still slow, it's probably sqlite | 21:00 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 21:01 | |
| RP | JPEW: perhaps you can help me understand where the bottleneck is. | 21:05 |
| RP | JPEW: I delete the unihash cache file, start a bitbake-hashserv, then run a "bitbake core-image-sato -kn". | 21:05 |
| RP | JPEW: what I then see is 6200 open connection to hashserv for over 30s | 21:06 |
| RP | JPEW: number of connections ~= number of tasks. I have to wonder why. I did already try and context manager around the urlopen() | 21:06 |
| RP | JPEW: definitely having performance problems. Last build was rather a mess :( | 21:08 |
| JPEW | Is the confusing part that there is are 6200 queries, or that each one is a new connection? | 21:08 |
| *** rewitt <rewitt!~rewitt@134.134.139.76> has quit IRC | 21:09 | |
| RP | JPEW: there are 6200 *connections* open | 21:10 |
| *** rewitt <rewitt!rewitt@nat/intel/x-lrrrfyhbatzmlhyu> has joined #yocto | 21:10 | |
| RP | JPEW: so each one is a new connection | 21:10 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 21:12 | |
| JPEW | RP: Are the connections stuck in TIME_WAIT state perhaps? | 21:13 |
| RP | JPEW: yes | 21:13 |
| JPEW | RP: 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 AFAIK | 21:17 |
| JPEW | RP: 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 once | 21:19 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 21:19 | |
| *** agust <agust!~agust@p54833DBB.dip0.t-ipconnect.de> has quit IRC | 21:21 | |
| RP | JPEW: I need to check what state things are sitting in | 21:24 |
| *** kukela_cd <kukela_cd!ae63deca@174-099-222-202.biz.spectrum.com> has quit IRC | 21:25 | |
| *** adelcast <adelcast!~adelcast@130.164.62.197> has quit IRC | 21:29 | |
| JPEW | RP: 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 faster | 21:36 |
| *** kaspter <kaspter!~Instantbi@183.128.238.14> has quit IRC | 21:38 | |
| RP | JPEW: no problem, I will need to sleep shortly too | 21:40 |
| *** kaspter <kaspter!~Instantbi@183.128.238.14> has joined #yocto | 21:40 | |
| RP | JPEW: I'm a bit fried after the other runqueue stuff tbh | 21:40 |
| RP | JPEW: I'm hoping there is something obvious/easy we're missing and can fix | 21:41 |
| Saur | RP: 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 |
| RP | Saur: you could see if master-next is any better | 21:54 |
| RP | Saur: clearly there is a problem and its not fit for purpose at the moment :( | 21:56 |
| Saur | RP: 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 |
| RP | Saur: so you're saying master-next made things worse? :/ | 21:57 |
| Saur | However, I do not know if those changes were the cause or it was just a coincidence. | 21:57 |
| Saur | That build was weird anyway, so probably best not to give it too much credit. | 21:57 |
| RP | Saur: 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 merging | 21:59 |
| RP | Its trying to do everything in parallel that is driving me crazy :/ | 22:00 |
| Saur | RP: Wish I could help you. Unfortunately, when it comes to bitbake itself my knowledge is superficial at best. | 22:01 |
| RP | Saur: I think a good benchmark is "bitbake X -n" on a clean build directory fwiw | 22:01 |
| RP | Saur: it might be helpful to figure out where in master we regressed and if that "benchmark" does show it | 22:01 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ztzsqwhfeccguwtm> has joined #yocto | 22:12 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:37 | |
| Saur | RP: It seems to be commit 1f630fdf in bitbake that introduces the delays. | 22:46 |
| JaMa | RP: with bitbake master-next update from today, I'm now seeing: /bitbake/lib/bb/data_smart.py:89: ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 46449)> not sure if it's related to delays | 22:54 |
| Saur | Anyway, I'm off, but maybe that info can give you some idea where to look for the cause of the delays. | 22:55 |
| khem | RP:I was giving a go to hash things, I have disabled it for now | 22:59 |
| khem | RP: building full oe layers with bunch of bsp layers ends up with a world build with 45k tasks | 22:59 |
| khem | so speed is need | 22:59 |
| khem | for now | 23:00 |
| khem | RP: ran -c testimage on rpi3 as well. Runs fairly well except few things, oeqa is very specific to messages coming from tested machines | 23:01 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:01 | |
| *** lexano__ <lexano__!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has quit IRC | 23:14 | |
| *** nick0001 <nick0001!48cb490f@ip72-203-73-15.oc.oc.cox.net> has joined #yocto | 23:18 | |
| *** lexano__ <lexano__!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto | 23:27 | |
| nick0001 | Hello. 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 perl-native_5.24.4.bb file (where the problem is reported) to no | 23: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 |
| khem | you should check the newly added layers for setting global config metadata | 23:50 |
| khem | some layers are notorious | 23:50 |
| *** moto-timo <moto-timo!ttorling@fsf/member/moto-timo> has quit IRC | 23:58 | |
| *** tgraydon <tgraydon!tgraydon@nat/intel/x-leycmqxqywdmlprb> has quit IRC | 23:58 | |
| *** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto | 23:58 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!