**** BEGIN LOGGING AT Fri Sep 08 03:00:00 2017 Sep 08 06:48:28 hi, i have the following error : Sep 08 06:48:29 the basehash value changed from b1f50b27e76fbe29359674047aa51698 to 3b60409f1511a691e6111691bd12d6f9. The metadata is not deterministic and this needs to be fixed. Sep 08 06:49:05 on a recipe I would like to know what changes during the build. does anyone knows How I can do this? Sep 08 09:16:07 hello everybody, someone can explain to me how VIRTUAL-RUNTIME_base-utils should work ? I have replace busybox with toybox but the generated core image have a bash dependency, i would like to use lightwight shell instead like dash but i don't understand why bash is installed. Sep 08 09:21:08 Hi, I create a custom BSP. My Image creation recipe fails because `parted` is missing. Where is the correct place to include `parted-native`? Sep 08 09:21:59 Is it intentional that CONFIG_HIDRAW is not set in linux-intel for MACHINE=intel-corei7-64? Sep 08 09:22:35 I just learned that this breaks fwupd. Not sure about other libudev-based USB applications. Sep 08 10:08:52 ipuustin: you mentioned an update of the checkgroup polkit replacement recently. Does it now allow packages to install their own rule files? Sep 08 10:09:40 I am experimenting with fwupd, and it uses polkit. For example, authorization for "org.freedesktop.fwupd.update-hotplug-trusted" was just denied. Sep 08 10:17:37 RP, rburton: so I was a bit surprised/confused about the machine triple in gcc being arm-unknown-linux-gnueabi even though I asked for a hf tune in the machine file Sep 08 10:18:06 it doesn't look like _anything_ in Yocto will generate/grok the real triple I'm after - arm-linux-gnueabihf Sep 08 10:18:20 if I just set TARGET_MACHINE myself, will everything explode in a huge fireball? Sep 08 10:19:01 ie, do I need to grep the whole tree for gnueabi and make them match gnueabihf as well Sep 08 10:20:17 this is probably unrelated to my actual problem, because some of the "armhf" ABI that distros agreed is just down to tunes which aren't represented by the machine triple, but having the wrong triple is far more likely to cause other build systems to set their cflags wrongly, and (given the tunes may or may not get applied to the target gcc) increases the chance the gcc defaults are wrong Sep 08 10:24:10 ramcq: our codebase uses "eabi", not "eabihf" but it should generate hf binaries Sep 08 10:25:06 right Sep 08 10:25:33 but we're producing an SDK for people to build stuff with their own build systems, not with the benefit of yocto setting their CFLAGS and such like Sep 08 10:25:57 so taking an actually hf compiler that claims to be an el compiler, and then expecting everyting to work, seems error-prone Sep 08 10:26:15 at least I was utterly confused/terrified and ran through the hills screaming with anguish Sep 08 10:26:31 :) Sep 08 10:27:46 am I wrong to be concerned and everything will be hunky dory Sep 08 10:38:32 ramcq: you're not wrong to be concerned however if they don't pass the right flags in it will break in a pretty obvious way, it won't silently do something subtle and nasty Sep 08 10:39:09 ramcq: and there are other flags needed like the sysroot and so on so even if you build a compiler with the "right" defaults, it won't solve all the potential issues Sep 08 10:39:58 ramcq: the compiler doesn't "pretend" to be one thing or another, just has a set of default options Sep 08 10:41:49 RP: sysroot isn't needed as the flatpak 'sdk' is actually a target system Sep 08 10:42:10 half the problem with talking to flatpak is the overloading of 'SDK' ;) Sep 08 10:42:18 rburton: oh, right, this is not our SDK, right Sep 08 10:42:30 * RP keeps forgetting that, its target gcc in our sense Sep 08 10:43:14 yes, which seems something of an after thought, kind of reasonably given this is after all a different build system :) Sep 08 10:43:28 so yeah I am worried about the subtle nasties Sep 08 10:43:55 anecdotally (we didn't test all of them) the crop of arm flatpaks on flathub seem less reliable/performant than the ones from the EOS build system (debian toolchain) Sep 08 10:44:03 so I think we do have toolchain gremlins Sep 08 10:44:20 ramcq: did you manage to at least get the neon default? Sep 08 10:44:54 ramcq: if so, it should be possible to make hf the compiler default too, regardless of the triplet Sep 08 10:44:58 no, I lost a lot of time yesterday because I was trying to do the build inside a flatpak sandbox because I didn't have root Sep 08 10:45:45 which introduced gremlins (maybe even because the compiler it was using then self-identified as armel but wasn't...? :P) Sep 08 10:46:03 the gremlins disappeared once I stopped sandboxing and I've got sudo to badger the build box if I need Sep 08 10:46:27 cool Sep 08 10:46:28 I didn't really understand the purpose/meaning of target_cpu_default however, so I was actually stuck when it came to making the change you pointed out Sep 08 10:47:16 also I'm having cold feet about the neon tune anyway, at this point I'd prefer to be doing the same as armhf Sep 08 10:47:50 I was roughly wondering about EXTRA_OECONF_append_blabla in a gcc-6.2.bbappend and just pushing in the same configure flags that Debian uses for armhf Sep 08 10:47:58 ramcq: I think you posted a link which I didn't have a chance to look at the time but is there a way I can reproduce this? Sep 08 10:48:02 so thumb2, vfp3-d16, hard, etc Sep 08 10:48:21 ramcq: have you those flags handy? Sep 08 10:48:44 I can dig them out relatively quickly Sep 08 10:49:15 ramcq: please, that might help me be more useful Sep 08 10:49:18 https://github.com/flatpak/freedesktop-sdk-base/ has our yocto layer and the (relatively light) scaffolding around it to take the image tarball and shove it in to an ostree Sep 08 10:50:12 pretty much git clone, submodule --init --hate --recursive -- whatever get the thing, then make Sep 08 10:50:18 (on an armhf machine) Sep 08 10:51:48 i suspect a minimal reproducer would be to build a target gcc for qemuarm and verify the flags are the right ones when its used inside qemu Sep 08 10:51:56 might need a fiddled qemuarm to get something that isn't arse though Sep 08 10:52:44 rburton: that was what I tried previously... Sep 08 10:53:09 ramcq: so you're building this on an armhf machine too (just so I'm clear what is happening here) **** BEGIN LOGGING AT Fri Sep 08 10:56:16 2017 Sep 08 10:59:55 and I think the gcc ./configure flags are... --with-mode=thumb --with-fpu=vfpv3-d16 --with-arch=armv7-a --with-float=hard --target=arm-linux-gnueabihf Sep 08 11:05:27 (nb the tune there is not the current DEFAULTTUNE in our custom qemuarmv7 machine, but my intention is to change it so we precisely match armhf in distro-land) Sep 08 11:06:01 if I set TARGET_MACHINE=arm-linux-gnueabihf how badly would everything break? :) Sep 08 11:11:27 ramcq: I'd suggest trying EXTRA_OECONF += "--with-mode=thumb --with-fpu=vfpv3-d16 --with-arch=armv7-a --with-float=hard" Sep 08 11:11:27 CONFIGUREOPTS := "${@d.getVar("CONFIGUREOPTS").replace("--target=${TARGET_SYS}", "--target=arm-linux-gnueabihf")}" in your bbappend Sep 08 11:12:00 cool Sep 08 11:12:13 ramcq: the TARGET_MACHINE variables doesn't exist so that wouldn't break anything ;-) Sep 08 11:12:46 ramcq: the issue we we had to patch in "gnueabi" support in a lot of places and i'd imagine gnueabihf is worse Sep 08 11:14:15 ramcq: you may need that CONFIGUREOPTS line in a binutils bbappend too if you want binutils to match Sep 08 11:18:13 ok, will give that a shot after lunch Sep 08 11:18:15 thanks! Sep 08 11:40:52 halstead: QA is also on the prowl for the 2.2.2 rc2, Thanks again! Sep 08 11:46:45 halstead: opensuse423 failed selftest as the user does have a git config (ERROR: Your git configuration is incomplete which will prevent rebases from working) Sep 08 11:46:54 halstead: erm, *doesn't have* Sep 08 13:05:05 libby1, It's almost ready i need to copy in some files from nightly-x32. Sep 08 13:06:30 halstead: nice thanks! Sep 08 13:31:51 rburton, I'm trying to see what could have caused that since the last successful one on that worker https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/488 Sep 08 13:49:27 RP: I sent the kernel class fixes for the AB error Sep 08 13:50:04 libby1, https://autobuilder.yocto.io/pub/releases/yocto-2.2.2.rc2/ is ready I think. Look at the nightly-x32 parts to see if anything is missing. Sep 08 13:56:23 halstead:Thanks Sep 08 14:03:00 Anyone have any idea what this warning means? WARNING: doorbell-apps-1.0-r0 do_package: QA Issue: doorbell-apps: Files/directories were installed but not shipped in any package: Sep 08 14:03:17 then theres a list of files and directoris that Im telling it to create. Sep 08 14:18:36 anyone else seeing this? Sep 08 14:18:39 fatal: unable to connect to git.pokylinux.org: Sep 08 14:18:39 git.pokylinux.org[0: 192.64.119.254]: errno=Connection timed out Sep 08 14:44:43 paulg_, The pokylinux.org domain isn't used anymore. Can you update to git.yoctoproject.org ? Sep 08 14:46:23 paulg_, The way the the redirects are set up changed recently and caused this to stop working. I can restore the old set up for a bit if needed. Sep 08 14:48:44 halstead, no don't bother; I'll fix it locally - it is a machine I've not used in a while. Thanks for the clue. Sep 08 14:49:35 paulg_, I've fixed it for now and will announce the change since this happened without notice. Sep 08 14:51:51 ok, cant hurt - there might be others that run into the same thing. Sep 08 14:59:11 Thank you for the report paulg_ :) Sep 08 14:59:26 no problem Sep 08 14:59:50 for some reason I had the stale name in meta-intel but not in any other of the meta-* I had on disk. Sep 08 15:00:31 so maybe there is an intel doc out there that still listed the old name at the time. Sep 08 15:00:41 * halstead nods. Sep 08 15:22:44 RP: so passing --target to binutils changes the path of the stuff it outputs, which makes the recipe fail Sep 08 15:23:00 (the patched gcc is still building, but the same could well happen there) Sep 08 15:28:33 ramcq: I'm pretty sure you'll at least get something which works better even without the target option. I can look into that error Sep 08 15:28:44 thats what I'm thinking Sep 08 15:29:03 like I'm very confident that (if gcc builds) this will actually give us the ABI I'm looking for, even if there is an identity crisis Sep 08 15:54:44 RP, ping Sep 08 15:57:25 nm, sending email Sep 08 16:10:55 armpit: here Sep 08 16:19:18 RP sent you an email regarding FC25 Sep 08 16:20:45 armpit: basically, yes, lets disable it Sep 08 16:22:12 k. is this weekend clear for stable builds or do you need to get some run time for master? Sep 08 16:24:49 armpit: fairly clear, we can likely do some of both Sep 08 16:30:21 hi Sep 08 16:30:40 how to escape $ on variable assignment in bb files ? Sep 08 16:33:05 RP, thank. have a good weekend Sep 08 17:08:05 RP, armpit anything to queue up on ab.yocto.io? Sep 08 17:08:48 not yet for stable Sep 08 17:09:28 halstead, need it for maint? Sep 08 17:09:46 armpit, Just finished. I want to start something to see if I mucked anything up. Sep 08 17:10:08 k, I will toss morty on it in a few Sep 08 17:10:21 THanks. Sep 08 17:15:37 build started Sep 08 17:25:49 halstead: any issues with git right now? Sep 08 17:26:25 halstead: I mean git.yoctoproject.org, not the OE one Sep 08 17:31:52 https://stackoverflow.com/questions/37744110/how-do-i-escape-a-in-bitbake-yocto Sep 08 17:31:59 does not really help Sep 08 17:33:08 RzR: there's no way to prevent expansion of ${} without making it so bitbake doesn't see it, as the response says. if you would, please open a bug so we can add the ability to do so. It's a long standing weakness in the file format / variable reference syntax Sep 08 17:33:46 Note Sep 08 17:33:46 BitBake does not interpret escape sequences like "\n" in variable values. For these to have an effect, the value must be passed to some utility that interprets escape sequences, such as printf or echo -n. Sep 08 17:33:56 is written in documentation Sep 08 17:34:31 yes... and? Sep 08 17:34:33 usual way to stop bitbake expanding is echo "something ... $""{....}" Sep 08 17:34:38 i don't see what ht ahs to do with the ability to escape ${} Sep 08 17:34:44 (not sure about the context exactly, but I've used that a lot Sep 08 17:35:39 fray, I need to set a variable to something that has a $... in Sep 08 17:35:45 escape sequences INSIDE of a variable is something compeltely different Sep 08 17:35:56 yea this is my case Sep 08 17:36:25 you can set to '$foo' but not '${foo}', as the later will be further expanded Sep 08 17:36:42 if you need to do the later, you need an alternative way of handling this.. something like Sep 08 17:36:50 for some reason it's not following .. Sep 08 17:36:54 BAR = "%{foo}" Sep 08 17:37:16 echo "${@d.getVar("BAR").translate('%', '$')}" Sep 08 17:37:40 or you can do: Sep 08 17:37:44 BAR = "${foo}" Sep 08 17:37:54 echo "${@d.getVar('BAR', False)}' Sep 08 17:37:54 but I want a variable to be assigned to $foo Sep 08 17:37:59 (False says don't do further expansion) Sep 08 17:38:01 literally Sep 08 17:38:05 that should work fine Sep 08 17:38:22 where is echo evaluated ? Sep 08 17:38:24 BAR = "$foo" should return $foo Sep 08 17:38:48 TARGET_LDFLAGS_append = '\$' Sep 08 17:38:48 presumably your vairable is used in a task.. the echo was just a usage exampel for shell tasks Sep 08 17:38:48 TARGET_LDFLAGS_append = 'ORIGIN' Sep 08 17:38:52 I was I use now Sep 08 17:38:56 $foo isnt expanded by bitbake at all, that's shell syntax Sep 08 17:38:58 but it does not work Sep 08 17:39:17 RzR that won't work, and it's not bitbake -- it's the users of TARGET_LDFLAGS may not handle shell escapes and such.. Sep 08 17:39:23 echo $LD_FLAGS is working Sep 08 17:39:32 but not with ld Sep 08 17:39:46 denix, Yes. we are getting some timeouts. I'm working on moving it today. Sep 08 17:39:47 use bitbake -e.. you will see it is set to '\$ORIGIN'.. it's not bitbake expanding it.. it's the user of that vairable that is expanding it Sep 08 17:40:01 bitbake -e will show you the raw value.. Sep 08 17:40:07 denix, Sorry for interruptions there weren't supposed to be any. Sep 08 17:40:14 this is never supposed to be evaluated Sep 08 17:40:24 the users have to know to escape everything... and many users pass things raw on the shell or via print or echo or... Sep 08 17:40:29 $ORIGIN is a gcc literal Sep 08 17:40:32 so in essence what is likely happening is: Sep 08 17:40:39 (bitbake) FOO = "$ORIGIN" Sep 08 17:40:43 (task -- shell call) Sep 08 17:40:51 ld ${FOO} Sep 08 17:41:00 not there is no $ORIGIN Sep 08 17:41:02 ;) Sep 08 17:41:05 so the shell is called with 'ld $ORIGIN', and thus the shell interpreter expands $ORIGIN Sep 08 17:41:14 take it as a string that has a $ inside Sep 08 17:41:18 as we just said, bitbake does not expand $FOO at all, ever. it's the shell doing it Sep 08 17:41:18 it's not a variable Sep 08 17:41:28 correct, it's the usage of this -- not bitbake Sep 08 17:41:34 bitbake calls bash.. bash expands.. Sep 08 17:41:45 bitbake (via tasks) may stuff this into a makefile.. makefiles with expand $... Sep 08 17:41:46 etc.. Sep 08 17:41:56 since it's the shell doing it, you can escape it the same way you'd escape it in any shell, with \ Sep 08 17:42:05 so I could prevent it to be expended by excaping it ? Sep 08 17:42:08 To use '$ORIGIN' in a CFLAG or LDFLAG, you would need to sanitize all users.. it's unlikely you'll be able ot do that Sep 08 17:42:34 depends on how many shell expansions occur between now and the usage, which is not easy to know without analyzing the buildysstem in question or trial and error.. Sep 08 17:42:38 in my experience, anyway.. Sep 08 17:42:48 ok this is frustrating Sep 08 17:42:58 I will use a workaround for now Sep 08 17:43:01 you can see exactly what is happening by inspecting the work dir 'temp/run.do_' you'll see that it's being spit out 'raw' there.. and it's the shell or make or something else expanding it (outside of the control of bitbake) Sep 08 17:43:05 halstead: thanks. do you know if there are any commits missing? our trees haven't been updating for few hours - I can re-push the changes once everything is fixed on the server... Sep 08 17:43:07 to be clear, you'd have the same issue trying to set it at a commandline via a variable Sep 08 17:43:12 not specific to use of bitbake here Sep 08 17:43:19 yes Sep 08 17:43:37 Thanks anyway this stuff was driving me crazy ;) Sep 08 17:44:00 denix, None are missing. If you find otherwise please let me know. Sep 08 17:46:01 halstead: well, for example meta-ti is mirrored to other locations and git.yoctoproject.org copy is now behind... if it was due to server issues, other trees might be affected too Sep 08 17:46:38 hey I think I am one step toward what I wanted Sep 08 17:47:20 denix, I've only seen git:// protocol interruptions. Anything pushing via ssh should be fine. Did you see a failed push to meta-ti ? Sep 08 17:48:49 denix, the last push I see is "2017-09-05.21:57:45 ti-robot" how far behind are we? Sep 08 17:53:07 halstead: yeah, it was failing to push earlier today to git.yoctoproject.org, but a second mirror at arago-project.org was working fine. the delta is just couple commits for now - http://arago-project.org/git/?p=meta-ti.git;a=summary Sep 08 17:53:17 Yes It worked Sep 08 17:53:57 now cleaning this: Sep 08 17:54:00 TARGET_LDFLAGS_append = ' -Wl,-rpath-link=' Sep 08 17:54:00 TARGET_LDFLAGS_append = "\\$" Sep 08 17:54:00 TARGET_LDFLAGS_append = "$" Sep 08 17:54:00 TARGET_LDFLAGS_append = "ORIGIN" Sep 08 17:54:05 denix, Shall catch it up or can you? Sep 08 17:55:21 RzR: no need for that to be on multiple lines, as we already said, bitbake won't expand it Sep 08 17:58:51 yea, I am checking this and will send patch ;) Sep 08 17:58:55 halstead: just trying to figure out on which side the issue is :) do you see anything in the logs? otherwise I'd need to get the logs for that ti-robot account on our end... Sep 08 18:01:50 denix, Nothing about ti-robot after that date. Reading auth logs. Sep 08 18:09:12 denix, It doesn't look like any failed attempts since Sep 5 21:57:45 either. Sep 08 18:14:55 halstead: ok, thanks! I'll dig on my side then Sep 08 18:15:26 denix, Okay. Let me know if I can help or should sync them from here. Sep 08 18:16:32 https://scontent.fsnc1-1.fna.fbcdn.net/v/t1.0-9/11223708_10156033928305154_8811768499638713569_n.jpg?oh=55e6b6891c247dd44db18a797b8b5c3f&oe=5A535167 Sep 08 18:16:32 halstead: will do Sep 08 18:16:38 OT, but amusing Sep 08 18:19:01 and just a little bit sad, because it's truth Sep 08 18:19:34 yep Sep 08 18:50:39 armpit, What are the Fedora25 issues? Sep 08 18:51:17 something to do with KVM running out of memory. Sep 08 18:51:47 there is a bug opened about it Sep 08 18:52:22 12058 Sep 08 19:04:50 hi, i'm building a image and when do_rootfs runs it gets a python error:"nicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 60080: ordinal not in range(128)" Sep 08 19:05:14 have you seen this before? Sep 08 19:10:43 I think that's supposed to be UnicodeDecodeError Sep 08 19:20:26 halstead: any recent updates on the server within past couple days? more stricter ssh algos, etc? from our side it says "ssh_exchange_identification: Connection closed by remote host" and "fatal: Could not read from remote repository." which are rather generic... Sep 08 19:21:12 denix, There are lots of zombie processes filling the table. No changes recently though. Sep 08 19:21:25 halstead: btw, let me know if you want to move to private, if others here don't have any issues pushing to git... Sep 08 19:22:02 denix, I'm happy either way. Feel free to PM. Sep 08 19:24:28 Does anyone know when/why kernel modules started depending on the "kernel-image" package? Seems that they're pulling in a kernel image on rpi on master branch when it's not needed Sep 08 19:27:12 paulbarker: Sep 08 19:27:13 # Allow machines to override this dependency if kernel image files are Sep 08 19:27:13 # not wanted in images as standard Sep 08 19:27:13 RDEPENDS_kernel-base ?= "kernel-image" Sep 08 19:27:17 from kernel.bbclass Sep 08 19:27:24 just set that to the empty string and you're good Sep 08 19:27:26 I already have that overridden Sep 08 19:27:27 paulbarker: there was this fix - http://cgit.openembedded.org/openembedded-core/commit/?id=5dd7ddb66a6846d9bb59dc7833e8318992d0e645 Sep 08 19:27:30 still pulling it in Sep 08 19:28:11 denix: I think I see the issue Sep 08 19:28:28 That switches out extra_depends='kernel-%s' % (d.getVar("KERNEL_VERSION")) Sep 08 19:29:03 Which would be something like kernel-4.9.... which depends on kernel-base Sep 08 19:29:17 And switches in a direct RRECOMMENDS on kernel-image Sep 08 19:29:26 ah, it's bypassing the kernel-base indirection Sep 08 19:29:27 that's bad Sep 08 19:29:33 So even with RDEPENDS_kernel-base empty it's pulling it in Sep 08 19:29:34 Yep Sep 08 19:29:41 you can still avoid it, but now you need BAD_RECOMMENDATIONS *too* Sep 08 19:29:41 Looks like it should be easy to fix Sep 08 19:29:42 yep Sep 08 19:30:10 someone didn't know about RDEPENDS_kernel-base and wanted to control it with BAD_RECOMMENDATIONS Sep 08 19:30:11 BAD_RECOMMENDS isn't something friendly to put in a machine conf file Sep 08 19:30:49 I'll send a patch to do the recommend on kernel- as before Sep 08 19:31:00 cheers for the quick pointers :) Sep 08 19:31:05 np Sep 08 19:31:39 yeah, well spotted denix Sep 08 19:32:40 kergoth: yeah, I was scratching my head with that change as well, thought I might have missed some previous discussion Sep 08 19:34:08 kergoth, paulbarker: do we need to completely revert that commit or there's a way to have both methods? Sep 08 19:34:26 No, I think it partially makes sense Sep 08 19:34:44 It just should add a recommend for the kernel- package not the kernel-image package Sep 08 19:35:49 You'd need to BAD_RECOMMENDS kernel- then, but that would be more correct Sep 08 19:36:40 paulbarker: ok, thanks. looking forward to your patch then Sep 08 19:38:24 yeah, best to switch form kernel-image to kernel, so it goes through kernel-base again Sep 08 19:38:27 hmm Sep 08 19:38:48 Actually, yea, the current code is bad as it means kernel modules won't pull in the files in kernel-base (which is modules.builtin and modules.order) Sep 08 19:39:12 I don't know enough kernel plumbing to know if those files are important to module loading Sep 08 19:40:50 I'm back to an empty /boot at least saving ~25% of my rootfs size Sep 08 19:59:09 FYI anyone interested in meta-selinux.. I've posted an update in the mgh/master-next branch.. I'm looking for help to get the refpolicy issues resolved.. (See email sent to the yocto project list) Sep 08 20:08:06 kergoth, denix: I changed my mind, I've sent an email to say I think we should revert the patch. Much simpler Sep 08 20:41:52 fray, if you can't login its very secure ; ) Sep 08 20:43:01 fray, i will bring it to the attention of the folks who should care about selinux Sep 08 20:43:08 thanks.. Sep 08 20:43:22 I've got a serious lack of time to look at the refpolicies.. Sep 08 20:44:08 Hello. I was wondering if I can have populate_packages_prepend in both my recipe and a bbappend to my recipe? Sep 08 20:45:14 and if it works, then can I set the order of the two prepends? I wast the recipe's prepend to be applied first followed by the one in the bbappend Sep 08 20:50:09 I've got another one I can't find the answer to in the docs... If I have a task (do_compile), is there any way to list which variables bitbake thinks that depends on? Sep 08 20:51:06 Things aren't being rebuilt when I change variables in local.conf and I want to check my suspician that they're being missed out of the dependency tree Sep 08 21:08:04 bhargav: prepends are cumulative, so yes, and no, you can't directly control the order Sep 08 21:08:11 paulbarker: bitbake-dumpsig Sep 08 21:09:50 kergoth: Just tried it, I get "Metadata does not support finding signature data files" Sep 08 21:10:33 bitbake -e shows the contents of do_compile with the new variable values in, the run.do_compile file shows the old files, but bitbaking the recipe doesn't lead to do_compile being re-ran Sep 08 21:11:10 I could just force it but if there's a weird dependency edge case I'd like to debug it a bit Sep 08 21:16:27 eugh. Changing the variable, running bitbake, then changing back, then running bitbake again caused it to pick up the change. Don't think I'm going to be able to get to the bottom of what went wrong there Sep 08 21:19:31 kergoth: I just tried, and the prepend from the bbappend was on top and I want the one from the bb file to be on top Sep 08 21:20:15 I wish we could do python populate_packages_prepend_append () Sep 08 21:20:45 basically append to a python populate_packages_prepend section in a recipe Sep 08 21:23:24 oh. I found it. It's not the recipe I'm looking at which has issues. I'm missing things from do_image_wic[depends] and thus it's picking up old nonsense Sep 08 21:37:26 halstead, yocto.io had no system issues. build completed. thanks Sep 08 21:40:35 armpit, thank you for the test. Sep 08 21:42:36 np Sep 08 22:30:45 Hello. In trying to upgrade from Morty to Pyro, I'm getting compile errors on qtbase/5.8.0. Has anyone else tested this? Sep 08 22:31:02 I got two different errors in sequence, so I did a clean and am rebuilding to find the exact error. Sep 08 22:31:08 First error was on a " Sep 08 22:31:20 return -1L << 16;" in the embedded zlib. Sep 08 22:57:06 Seems to be a libpng issue, and the other was just a warning that came up. Sep 08 22:57:17 Project ERROR: Library 'libpng' is not defined. Sep 08 23:37:54 Circuitsoft: share the build logs on some pastebin Sep 08 23:39:24 Fixed with a patch: https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commitdiff;h=4dcfd90e4fd7d4c49138038dbbcbda8794a9fbff#patch1 Sep 08 23:49:23 sgw, Are you having any issues with git.yoctoproject.org today? Sep 08 23:51:28 halstead: not that I am aware of Sep 08 23:51:45 sgw, Great. I've had 2 reports today and just wanted to check. Sep 08 23:51:54 Working on it. Sep 08 23:52:11 I can test something later if needed, heading out for a bike ride Sep 09 00:04:37 Have a good one. Thanks. **** ENDING LOGGING AT Sat Sep 09 03:00:00 2017