**** BEGIN LOGGING AT Thu Aug 01 03:00:25 2019 Aug 01 03:05:21 New news from stackoverflow: aarch64-poky-linux-gcc: error: : No such file or directory Aug 01 06:38:29 good morning Aug 01 07:05:55 New news from stackoverflow: How to load Yocto generated U-boot binaries to t1042d4rdb board Aug 01 08:06:16 hi. i'm trying to use multiconfig to customize a distro for different use cases: in my multiconfig/foo.conf, i define a variable `FOO`, but when building, i'm getting the error that "The metadata is not deterministic". Aug 01 08:07:30 am using multiconfigs correctly? or would i be better off to use different MACHINEs for customisation? Aug 01 09:54:54 Is anyone know how force -mcpu= during kernel compilation? Aug 01 09:55:25 powerpc-voltumna-linux-gnuspe-gcc: error: unrecognized argument in option '-mcpu=powerpc' note: valid arguments to '-mcpu=' are: 8540 8548 native Aug 01 10:47:23 hm -dbg packages relatively often contain absolute build paths in if they contain generated code Aug 01 10:47:28 ie anything generated by glib-mkenums Aug 01 10:59:26 rburton: that doesn't sound good. We're supposed to be stripping that out Aug 01 10:59:54 alessioigor: the kernel is notorious for doing things with its compiler options Aug 01 11:00:51 RP: meta-openembedded works as-is because it's not mentioned in the repo-defaults of the JSON file, so its layer(s) don't get added until run-config happens. The core of the problem for me was that one of the repos in NEEDREPOS depends on meta-openembedded's layers, so it would get added first during layer-config. Then when run-config attempts to run through ADDLAYERS, it fails because it can't parse my layer Aug 01 11:00:51 configuration (missing dependencies that I'm trying to add) Aug 01 11:15:04 tgoodwin: I'm not sure that is true: Aug 01 11:15:06 config.json: "NEEDREPOS" : ["poky", "meta-openembedded"], Aug 01 11:15:06 config.json: "NEEDREPOS" : ["poky", "meta-openembedded", "meta-virtualization"], Aug 01 11:16:24 tgoodwin: sorry, I think I misunderstood Aug 01 11:16:43 RP: neither one is listed in the repo-defaults, so that check in layer-config doesn't add them to the bblayers; they only get added (in the correct order) afterwards at run-config thanks to ADDLAYEr. Aug 01 11:18:06 The check I'm talking about is at the bottom of the layer-config file. If an item in NEEDREPOS isn't in the repo-defaults, it hits the continue. Aug 01 11:19:50 tgoodwin: I don't read the code that way. It can only hit the continue if its in repo-defaults Aug 01 11:21:04 Good call. Hmm.. Aug 01 11:23:03 tgoodwin: perhaps repo-defaults hould have a "sublayer" parameter which if set, would be interated and passed to add-layer Aug 01 11:23:23 I'm not sure how they're getting skipped either. When I was testing this yesterday I had to define the repo in repo-defaults with no-layer-add to get around this. Aug 01 11:23:30 (which makes sense given the code) Aug 01 11:24:00 tgoodwin: yes. I don't know how its "working" right now :/ Aug 01 11:36:43 New news from stackoverflow: Bitbake is failing for yocto build Aug 01 11:38:29 RP: It's a silent failure. Check the log for step 4: https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3 Aug 01 11:38:53 That's the result of running layer-config against "meta-openembedded" Aug 01 11:39:56 tgoodwin: ok, that raises the question about why that isn't erroring but does explain a lot! Aug 01 11:40:21 tgoodwin: I'm a little happier now we know what is happening! Aug 01 11:43:40 RP: same :) I think it's because the "ret" in bitbakecmd doesn't percolate out of layer-config as a bad return code. Aug 01 11:44:35 Perhaps move the "if ret" down to the for loop and return "ret" from the function, or maybe use check_call so that the exception can be caught in the loop as a return code. Aug 01 11:48:22 PR: is the preference for the script to try to perform all actions or abort at the first error? Aug 01 11:49:44 tgoodwin: it should abort if there is an error Aug 01 11:51:03 What I mean is, run-config's variation tries to run through all bitbake commands, totalling up the return values. Aug 01 12:05:55 tgoodwin: failures in execution are different to failures in setup IMO Aug 01 12:07:05 Hi, is there a way easy way to deploy a built package on the target via network? Aug 01 12:07:30 ThomasD13: devtool deploy-target Aug 01 12:09:07 Okay. As it seems, I need to have the specific package in the devtool workspace directory. Is there a way around this? So that I can just build and deploy "iperf" on the target for example? Aug 01 12:09:42 ThomasD13: only if you have package management on the target, AFAK Aug 01 12:10:37 Okay, so I need a package management on the target, which targets to a local package repository, whereas yocto deploys the packages? Aug 01 12:28:41 RP: Thanks! Aug 01 12:41:19 RP: I'm working on a patch for this locally and put in a request for access to the helper repo. Aug 01 13:01:04 tgoodwin: ok, thanks. Aug 01 13:14:21 RP: For some of those runqueue changes, you might want to consider using the "force keyword argument" operator for better compatibility going forward: `def validate_hashes(self, tocheck, data, *, currentcount=None, siginfo=None)` Aug 01 13:15:48 JPEW: how would that help? Aug 01 13:17:03 It means you can add new kwargs in any order, ignore them more easily if necessary, or add new positional arguments (if you *really* have to). Aug 01 13:18:57 JPEW: I guess I've assumed that with **kwargs, that would give us the ability to add new parameters and that was enough but I can see what you mean about extra args Aug 01 13:20:15 RP: Ya. I think it's a lot cleaner the generic **kwargs in a lot of cases (and a lot easier to deal with). Mostly, it enforces the "these must be kwargs" Aug 01 13:26:33 JPEW: since we already have kwargs, wouldn't that always be enforced though? Aug 01 13:33:39 RP: Ya, if you do `def func(**kwargs)` then keyword arguments are enforced on the caller. `def func(b=1, c=2)` can be called as either `func(3, 4)` or `func(b=3, c=4)`, but `def func(*, b=1, c=2)` can only be called as the latter Aug 01 13:35:05 JPEW: right, but I'm not sure that is a huge deal for us Aug 01 13:35:36 RP: Maybe not Aug 01 13:40:33 @rburton: thank you... I am at this point... however I am not sure how do_install() do_compile() should be to do the actual build and install Aug 01 14:36:11 upstreaming could sometimes take 2+ years but it works https://github.com/telmich/gpm/pull/20 Aug 01 14:36:42 OE has far better SLA Aug 01 14:39:34 nabokov: thats just a matter of building in each directory Aug 01 14:43:26 khem, lol Aug 01 14:43:39 Maybe this IS the right place to ask: I have a CMake project building for yocto and need to talk to a redis instance. For host dev I simply installed hiredis library. For bitbake, I included hiredis in my DEPENDS_${PN}, but now the Findhiredis.cmake (no need for a paste, it's everywhere already …) errors out. Aug 01 14:44:21 DEPENDS is recipe-wide not per-generated-package Aug 01 14:44:28 so DEPENDS="hiredis" Aug 01 14:46:34 rburton: d'oh *hands over beer* Aug 01 14:46:52 * rburton adds a qa check Aug 01 15:04:51 +1 on qa check, I've seen surprisng number of these in our layers and people even claimed that it fixed something :) Aug 01 15:09:59 patch sent Aug 01 15:10:23 only looks for DEPENDS_${PN} instead of looking for all DEPENDS_*, to avoid false positives at the cost of less accuracy Aug 01 15:10:36 pretty sure nobody will do eg DEPENDS_${PN}-doc though Aug 01 15:14:35 Hi everyone, I want to build a vanilla poky image off the master branch against glibc 2.26. What I've tried so far is to replace the glibc 2.29 recipes in meta/recipes-core and to touch some config files that seemed reasonable to me. Obviously I'm doing something wrong as bitbake complains about glibc depending on 'virtual/nativesdk-x86_64-pokysdk-linux-gcc-initial' but nothing providing it... Aug 01 15:15:03 I've uploaded the relevant changes and bitbake output on pastebin: Aug 01 15:15:13 https://pastebin.com/ysA3vRWx Aug 01 15:15:22 https://pastebin.com/wAb7n3Hb Aug 01 15:15:46 if you *really* need 2.26 why not use the release that shipped with 2.26? Aug 01 15:15:48 It would be really cool if someone could point me to the right direction.. thanks in advance! Aug 01 15:16:22 if you just grabbed the recipes from an old release and dropped them into master then yes, they'll break, because we changed how glibc/gcc bootstrap Aug 01 15:17:13 that's a bit complicated.. the reason I went for master is that I need the epiphany browser ver 3.31.4+ Aug 01 15:18:24 our production linux image is based on rocko, which builds against glibc 2.26 Aug 01 15:18:53 i'd definitely take the webkit/ephy recipe from master instead of trying to shoehorn old glibc into master Aug 01 15:20:35 yeah, that's what I had tried first but that epiphany version requires meson as build engine which seemed non-trivial to get into rocko either.. Aug 01 15:23:10 unfortunately, I don't have any build error logs for that approach at hand but I can retry it that way and get back with some logs Aug 01 15:44:15 rburton: Weird. CMake goes through now (and the logs look promising), but during compilation I get undefined references to the redis functions. wat Aug 01 16:02:23 jmiehe: probably because cmake is evil Aug 01 16:02:42 (its probably doing something stupid like trying to link to the host libraries?) Aug 01 16:09:42 wanted: a volunteer to boot-test a pile of qemu images. Aug 01 16:16:06 genuine request: if anyone wants to clean up the graphics driver situation for the qemu machines (which is a mess) i'll happily guide Aug 01 16:56:45 rburton: do you know why the tunes on meta-intel are for Nehalem? Aug 01 16:57:09 aehs29: because when they were written that was a reasonable modernish tune Aug 01 16:57:19 rburton: I upgraded them for Skylake and the builds go fine until whatever uses a qemu wrapper craps out Aug 01 16:57:29 im just wondering if thats the reason Aug 01 16:57:41 thats the main reason why the skylake tune on the list isn't merged yes Aug 01 16:57:47 turn off qemu-usermode Aug 01 16:57:55 the problem is that qemu doesn't support avx2 Aug 01 16:57:57 (yet) Aug 01 16:58:23 yeah its theres illegal instrucions all over Aug 01 16:58:38 right, glibc happily goes to use avx for string ops and BANG Aug 01 16:59:07 is there an easy way to turn of user mode? Aug 01 16:59:14 yeah its just a machine feature Aug 01 16:59:17 as in is there a variable or something that Im not aware of Aug 01 16:59:39 rburton: ok thanks will take a look Aug 01 16:59:52 see [meta-intel] [RFC][PATCH] conf: add new machine intel-skylake-64 in the meta-intel list Aug 01 17:01:15 rburton: oh interesting, I shouldve checked the list before doing it myself haha Aug 01 17:03:04 rburton: thanks Aug 01 17:12:23 rburton, care to elaborate about the graphics driver situation? Aug 01 18:21:09 kanavin: sure there was another bug but i couldn't find it so https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466 Aug 01 18:21:10 Bug 13466: normal, Undecided, ---, ross.burton, NEW , qemu machines use Cirrus graphics, should use std or virtio Aug 01 18:22:04 kanavin: basically some qemu machines use cirrus graphics, some use vmware, some use std. step 1: stop using cirrus, move everything to std, verify it all still works (may involve kernel tweaks). step 2: try virtio graphics. Aug 01 18:22:34 i've part of the work in an old branch Aug 01 18:23:27 ah yes, one of the catche was that some qemu build configurations don't enable virtio-vga Aug 01 21:50:47 I'm trying to write a build script to use inside the SDK but having trouble getting the environment set correctly. If I source the environment setup script in a bash shell and run cmake, everything works great. However, in attempting to do the same inside a shell script cmake's find package is locating the native Boost rather than the one in the Aug 01 21:50:48 target sysroots. In both cases, 'type -a cmake' returns a correctly aliased cmake located in the host sysroots folder. Anyone have any insight into what I'm missing? **** ENDING LOGGING AT Fri Aug 02 03:01:07 2019