**** BEGIN LOGGING AT Thu Oct 17 02:59:57 2019 Oct 17 03:37:17 Morning all Oct 17 03:37:50 Anyone here about to help with compiling a OS called VenusOS so it will work on Pi4 (as well as 3 which it already works on) Oct 17 04:57:05 I have a simple application that I want to create a recipe for. I have created a very basic CMakeLists.txt file for it, and created a recipe skeleton with devtool add. WHne I try to build the recipe it complains about not being able to find errno.h. It feels like I am missing something very basic that screws up the cross compiler so it can't find standard headers. Any "typical newbie errors" that could Oct 17 04:57:11 case this? Oct 17 05:01:46 if the cmakelists.txt is done correctly and you inherit cmake, that's all you need to do Oct 17 05:17:13 So strange... If I build it using my SDK it works fine, but with devtool it cannot find errno.h. *headscratch*. I don't even know where to start looking. Oct 17 06:15:25 LetoThe2nd: Thanks! Oct 17 06:15:29 good morning to all! Oct 17 07:46:04 I want to debug a python function in a bbclass, how to execute that function specifically? Oct 17 07:49:05 armpit: I guess 2.6.4 is going to be the last dot release for thud. I'm thinking that the very little amount of time I possibly have to investigate the opkg BAD_RECOMMENDATIONS issue before 2.6.4 is released is not going to be enough, so maybe revert the patches? I'd rather have thud not working the same way it was from 2.6.0 to 2.6.2 (build failure for some specific cases) than what's currently in 2.6.3 Oct 17 07:49:11 which is basically ignoring BAD_RECOMMENDATIONS Oct 17 07:54:26 New news from stackoverflow: Loading custom u-boot script Oct 17 08:00:49 anyone here heard of VenusOS? Oct 17 08:01:22 Its a 32b rpi3 OS, that I would like to get going on Rpi4. It uses u-boot (a very old version) and apparently yocto Oct 17 08:05:34 al_nz1: we have pretty good support in meta-raspberrypi, see https://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/tree/conf/machine Oct 17 08:05:46 al_nz1: so feel free to pick whatever you need there. Oct 17 08:09:34 * mckoan wonders why one should use an open source system disguised as a proprietary system Oct 17 08:10:01 mckoan: *shrug* probably it contains some cool special sauce. Oct 17 08:10:21 it doesn't look outdated nor particularly stupid, so ... whatever. Oct 17 08:10:30 LetoThe2nd: like paying for the sourcecode? LOL Oct 17 08:10:55 mckoan: if they want to, why not? good marketing on the sellers side. Oct 17 08:12:11 * rburton is curious what LetoThe2nd is refering to Oct 17 08:12:36 rburton: https://github.com/victronenergy/meta-victronenergy Oct 17 08:13:56 isn't that just a companies own distro that theyve nicely made public Oct 17 08:15:03 https://www.victronenergy.com/panel-systems-remote-monitoring/octo-gx runs venus os Oct 17 08:16:37 LetoThe2nd: I like how you give me credit for having way more knowledge than you think I have Oct 17 08:16:39 not the best feeling to break upstream while trying to fix it :/ sorry all Oct 17 08:17:26 rburton: yeah i mean, no problem with it. when somebody wants to use it, why not. Oct 17 08:18:00 unless you have a need to use the venus stack on your hardware, i'd stick with normal yocto+meta-raspberrypi Oct 17 08:18:06 al_nz1: i actually am not sure what you mean." Oct 17 08:18:36 also consider using 64-bit because its better Oct 17 08:18:53 al_nz1: see rburton, thats what would be my choice too. and if you want their stack, then you're in for either combining the layers, or going to pick stuff. Oct 17 08:24:34 New news from stackoverflow: How to override the defined task order in a yocto recipe? Oct 17 09:17:59 is there any replacement for the old 'yocto-bsp' command? Oct 17 09:18:20 I mean a sort of guided BSP layer creation Oct 17 09:19:09 probably I missed something in the last releases Oct 17 09:19:14 no, from memory yocto-bsp was pretty bad Oct 17 09:19:42 (removed in sumo/2.5 onwards) Oct 17 09:19:56 rburton: so now you have to crete every single detail by hand Oct 17 09:20:49 I also noticed that bitbake-layers create-layer created a useless ecample recipe instead of the helloworld Oct 17 09:24:16 mckoan: the helloworld one was broken because of some linker flag stuff IIRC Oct 17 09:26:57 LetoThe2nd: in fact you needed to add TARGET_CC_ARCH += "${LDFLAGS}" Oct 17 09:27:17 mckoan: something like that, yes. Oct 17 09:43:15 hello folks! Oct 17 09:43:53 what's the rationale for not allowing bbappend on classes, or at least blacklisting classes? Oct 17 09:50:32 RP: ^^^ ? Oct 17 09:52:13 litb: probably the main reason is "nobody sent a patchset yet doing this" Oct 17 09:52:48 LetoThe2nd: no, its specific policy Oct 17 09:53:04 LetoThe2nd: it strongly encourages collaboration around the core bbclass files Oct 17 09:53:19 RP: ah ok? care to elaborate a bit so i can spread the wisdom if needed? Oct 17 09:53:51 LetoThe2nd: make it too easy to hack and nobody will make the effort to improve the core Oct 17 09:54:47 RP: thats certain. so in consequence it means "if you want to change that class, you need to derive it under a different name" Oct 17 09:55:10 which in turn means you can inject changes into depending recipes. so i can totally see the usecase. Oct 17 09:55:13 LetoThe2nd: you can replace it under the same name too Oct 17 09:55:19 but then you have to maintain a fork Oct 17 09:55:51 we just made it a little more painful so that people realise they should collaborate Oct 17 09:56:10 yeah i know. but that dpeends on priorities respectively bblayer ordering and is therefore kinda... meh Oct 17 09:56:27 LetoThe2nd: it does indeed depend on ordering Oct 17 09:56:32 shrug ;-) Oct 17 09:56:50 depends how much you really need to hack the class Oct 17 09:56:58 yeah Oct 17 09:57:25 Hm, but certain things may not be worth to be put into the core bbclass file Oct 17 09:58:02 so if someone has an exotic system and he needs to change a core bbclass file, the OE maintainers may shrug and say it's not spread widely enough Oct 17 09:58:29 litb: i guess its rahter "make sure its not affecting others" Oct 17 09:59:02 and of course, if its only your homebrew system for one usecase, it might be difficult arguing that it needs to be included. Oct 17 10:02:23 I understand its frustrating when it stops you doing something you feel you should be able to do but it has on balance served the project well overall Oct 17 10:02:37 There are usually other ways to work around such situations Oct 17 10:03:10 as long as it doesn't stop me from listening to metal and drinking beer, i'm fine :) Oct 17 10:05:48 litb: would you be able to elaborate on what you'd like to override specifically? Oct 17 10:10:06 i guess using event handlers and anonymous python functions and INHERIT, most often it is possible to work it around Oct 17 10:10:43 bluelightning, so far it was cmake.bbclass, which is not mingw compatible. and bash-completion, which put a hard dependency on bash into glib-2.0 Oct 17 10:11:08 this sounds very upstream-able Oct 17 10:11:11 the latter was able to be worked around by undoing the changes done to DEPENDS and RDEPENDS that was done by bash-completion, in the bbappend for glib-2.0 Oct 17 10:11:41 the first one was more troublesome, and I had to INHERIT a "correction class" cmake-mingw.bbclass that fights against cmake.bbclass oO Oct 17 10:12:55 * LetoThe2nd feels RPs reasoning apply Oct 17 10:14:01 hm, I see :p Oct 17 10:29:36 hello, I have a general question: if I want to migrate to Yocto "rocko" from "krogoth" is the kernel version relevant? because the board supports a custom 4.1 kernel Oct 17 10:30:37 files that are locally available in metadata doesn't go to DL_DIR,right? Oct 17 10:30:48 kayterina: rocko to krogoth sounds rather unfortunate, as thats going backwards... 3 years or so. Oct 17 10:31:16 xtron: don't think so, yes. Oct 17 10:32:07 kayterina: i'd rather try to get the kernel compile on rocko Oct 17 10:32:58 LetoThe2nd: It's a myirtech board and they ship with krogoth supported. You mean compile the 4.1 with their patches in rocko? Oct 17 10:33:49 kayterina: thats what i would do. and pester them to support something thats not completely out of support since years. Oct 17 10:34:15 4.1 should build on rocko given something like https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/compiler-gcc.h?h=linux-5.0.y&id=cb984d101b30eb7478d32df56a0023e4603cba7f included Oct 17 10:35:05 ok LetoThe2nd thanks Oct 17 10:36:02 perhaps you also know why freescale's "rocko" links point to "pyro" tree? I should still get the rocko right? Oct 17 10:36:20 it depends Oct 17 10:36:45 if a layer doesn't bring much, its very well possible that a single state matches several releases. Oct 17 10:37:12 or that fresscale does not support rocko on the very layer you are on Oct 17 10:37:15 or, or, or Oct 17 10:38:32 a, it's the fsl community layer. Oct 17 10:38:34 (read that as: if you've got a vendor that ships ancient software, and want to make it work with not-so-ancient-but-still-old software, you're in for the fun yourself) Oct 17 10:39:01 ha ha Oct 17 10:39:06 thats the way it is. Oct 17 10:39:18 the fsl community layer has been deprecated in 2016 Oct 17 10:39:29 -> https://lists.yoctoproject.org/pipermail/meta-freescale/2016-October/019429.html Oct 17 10:40:02 so, if you want to stick to that old state, "you're in for the fun yourself" Oct 17 10:45:13 I intended to bring the myirtech-layer+kernel 4.1 to work with rocko and the new meta-freescale layers(not fsl-arm* that are deprecated). Oct 17 10:46:05 it is just one layer, a few renamed variables, I'll see what else. I 'll try the kernel first as you said. Oct 17 10:47:37 have fun, then. Oct 17 10:47:49 :P Oct 17 11:05:32 kayterina: why rocko? sumo and thud and warrior (and zeus, this week) are all newer. Oct 17 11:05:47 https://wiki.yoctoproject.org/wiki/Releases Oct 17 11:05:55 rburton: i'm sympathetic. because ROCKo Oct 17 11:06:06 PSA rocko is unmaintained this month Oct 17 11:06:18 oh no its already unmaintained Oct 17 11:06:24 i just can't count Oct 17 11:06:59 rburton: thud is EOL in two weeks IIRC Oct 17 11:07:30 rburton: 10:38 < LetoThe2nd> (read that as: if you've got a vendor that ships ancient software, and want to make it work with not-so-ancient-but-still-old software, you're in for the fun yourself) Oct 17 11:12:55 rburton: I saw at freescale.github that the latest is rocko,that's all Oct 17 11:13:17 see i should stay away from irc when also on a call Oct 17 11:13:38 rburton: oh no, it massively adds to the fun! Oct 17 11:13:40 harass fsl if you want current yocto support on fsl hardware Oct 17 11:14:23 rburton: i repeat we do not harass. all we do are very polite and friendly reminders to other people to encourage them to SORT THEIR SHIT OUT :-P Oct 17 11:14:48 and if its dead, put a note on the repo to say so :) Oct 17 11:15:01 a very polite and friendly one! Oct 17 11:16:00 ok,ok,fsl and vendor both,I will ask nicely,I will not harass.back to the fun now Oct 17 11:29:45 hi Oct 17 11:30:16 what to do, if include files of dependend libs are not found? Oct 17 11:30:32 I have #include Oct 17 11:30:40 which is not found. Oct 17 11:30:47 you probably need to use pkgconfig or similar to find the paths Oct 17 11:30:57 but exists in recipe-sysroot! Oct 17 11:31:19 cc -o wand wand.c `pkg-config --cflags --libs MagickWand` <-- says the docs Oct 17 11:31:19 rburton: ah, ok. how? Oct 17 11:31:30 https://imagemagick.org/script/magick-wand.php Oct 17 11:31:45 your include is wrong too Oct 17 11:32:03 oh, sry, have written in from mind... Oct 17 11:32:06 let me see. Oct 17 11:32:21 kayterina: what about meta-freescale? http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale Oct 17 11:32:35 #include Oct 17 11:32:50 this is what I have in main. and it compiles perfect on target system. Oct 17 11:33:04 so the project compiles without error on target. but not in yocto. Oct 17 11:33:48 do you use pkgconfig in the makefile to find the right include path? Oct 17 11:34:16 BuddyButterfly: probably because your host system has the include path set somewhere you're not aware of. but this is not something one can rely on, as it will even break across linux distros. hence, yocto makes sure you do it in a robust way. and that means, properly do it by invoking pkgconfig. all buildsystems have proper support for it, BTW. Oct 17 11:34:42 of course there's a chance the imagemagick recipe is broken and nobody noticed until now Oct 17 11:35:08 just use "inherit pkgconfig" ? Oct 17 11:35:17 that, and the makefile needs to call it Oct 17 11:35:25 like the documentation i linked to says Oct 17 11:36:17 ok, will try, thanks for the "very" quick help. Oct 17 11:37:16 ? Oct 17 11:42:25 finally got around to writing a 'lockdown' script Oct 17 11:42:31 qschulz: that was my first thought, throw the vendor's layer in yocto and fsl latest, should I try to build their kernel with latest versions? Oct 17 11:42:36 sry, the "" was wrong. you really responded very quick! Oct 17 11:42:37 'i want to rebuild this one low level package without causing the universe to rebuild' Oct 17 11:43:09 rburton: i smeall breakage coming up, if people use that without a full understanding of the implcations. Oct 17 11:43:12 great for poking at target python without causing native python and thus rpm and thus everything to rebuild Oct 17 11:43:34 LetoThe2nd: hillarious behaviour if you forget its enabled Oct 17 11:43:38 WHY IS THIS HAPPENED Oct 17 11:43:56 thats what i mean Oct 17 11:44:06 need a way to make it shout loud that it is on Oct 17 11:44:27 the actual thing is trivial though and is basically just a bitbake call and a sed Oct 17 11:44:37 and i can instantly hear the n00bs... erm sorry, beginner users, who will try and use this to cut down build times on their vms because "all i want to change is..." Oct 17 11:46:56 RP: ok so how can i emit a warning message *from a conf file* Oct 17 11:47:01 RP: i'm guessing "you can't" Oct 17 11:54:29 in case of SRC_URI set to a local file, "url.localpath" will be none, causing a exception when this class pass it to os.path.exists(url.localpath)?: https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/classes/fsl-eula-unpack.bbclass?h=sumo-4.14.98-2.0.0_ga#n30 Oct 17 11:55:12 New news from stackoverflow: Adding new dts to Raspberry Yocto project Oct 17 11:58:28 kayterina: you can, though it might not just work (the kernel I mean). Basically, recipes which are BSP related (kernel, bootloader, signing scripts, and whatnot) will rarely be updated if they haven't been upstreamed. But it should be rather safe to take this BSP layer or only the recipes you want and add them to your newer layer. I personally think it's faster to try to fix a Yocto build for an old Oct 17 11:58:34 kernel/bootloader than trying to make a new kernel work. (but if you can afford making a new kernel work, go this route, maybe even upstream and you should technically be able to update to newer versions very easily) Oct 17 12:00:53 Hey, got a small bugfix in a linux v 4.9.11, where one line should be changed. My idea was to fix that using a .bbappend file in my own layer, using a sed command to just change that one line. For some reason I cannot get that change to actually be visible, although do_install logs show that my command has been run, and running the same command outside of bitbake makes the change I want. Oct 17 12:01:44 feilz: rahter pour it into a path, and add that to SRC_URI in your append Oct 17 12:02:30 ehh... how do you mean? Oct 17 12:04:16 assuming you mean making that change into a file Oct 17 12:04:32 what is the kernel besides files? Oct 17 12:04:59 LetoThe2nd: https://github.com/rossburton/bb/blob/master/libexec/bb-lockdown fwiw Oct 17 12:05:17 but... if I understood correctly then I would have to rewrite (or well, copy) the whole previous file instead of just fixing one line in that file. Oct 17 12:05:59 no, just patch the file Oct 17 12:06:02 i mean, you take the kernel checkout without your change. you do the change, and then do a git add, git commit, git format-patch (basically). then you have a patch file that hold exactly that one line change Oct 17 12:06:32 presumably you're sending the bug fix into the kernel anyway so you need a patch Oct 17 12:06:48 rburton: 4.9? not sure... Oct 17 12:07:02 maybe its still broken in master Oct 17 12:07:05 it's actually not in the kernel... but in the userspace Oct 17 12:07:14 not even if its 4.9.11, which smells like evil vendor kernel Oct 17 12:07:21 sorry, misleading in initial description Oct 17 12:08:16 what file are you actually changing Oct 17 12:08:30 feilz: you said "bugfix in linux 4.9.11, one line should be changed". to me that sounds pretty clear, TBH Oct 17 12:09:11 rburton: lockdown still gives me the creeps, sorry but have to say. Oct 17 12:09:36 qschulz: I don't know much about the kernel, I will go the simplest way, build their kernel with newer layers Oct 17 12:09:36 LetoThe2nd: you won't say that when you're trying to iterate a fix in python3 and every touch causes a glibc rebuild Oct 17 12:09:45 yeah, my bad. I said wrong. Oct 17 12:10:05 rburton: i will never ever say that i'm doind anything with py3, so thts no problem for me :) Oct 17 12:12:14 feilz: so what are you trying to change, and how. Oct 17 12:14:02 LetoThe2nd, and .bbappend for recipes can't prevent _append code from the actual appended recipe Oct 17 12:14:46 or is there a workaround? Oct 17 12:20:30 litb: i'd suggest that your life would be a *lot* easier if you were happy patching oe-core and working to get stuff upstream Oct 17 12:20:49 but for now you could just add a bash-completion class to your layer that does nothing Oct 17 12:21:06 get it working with hacks, and then clean the hacks Oct 17 12:22:38 hell, bash completion class could just need a toggle to control whether it does anything Oct 17 12:22:48 and then the windows machine turns it off Oct 17 12:25:18 New news from stackoverflow: How to use secure u-boot (HABv4) with mender on iMX6UL board Oct 17 12:26:35 rburton: pulseaudio.service file, using a .bbappend, which exists in meta-variscite-flsc branch rocko. Idea was to simply modify the incorrect line from 'Type=fork' to 'Type=forking' Oct 17 12:28:03 trying to write simply do_install_append() { sed 's/fork/forking/g' ${D}${systemd_unitdir}/system/pulseaudio.service } Oct 17 12:28:52 this line shows up as the correct path to the correct file in the logs, but the actual file i'm seeing doesn't contain the change. Oct 17 12:29:38 feilz: doesn't sed need -i to be in-place? Oct 17 12:30:02 feilz: in the systemd unit case, sed might be suitable. Oct 17 12:30:28 worked without -i using my own commandline. can attempt to rebuild with -i Oct 17 12:31:19 feilz: i'm not certain, just thinking aloud. Oct 17 12:33:25 is the 'sed' command used by bitbake different than what my system has? Oct 17 12:34:13 no Oct 17 12:34:26 kind of what I assumed... Oct 17 12:34:35 pretty sure you need -i to make that work Oct 17 12:49:14 seems like that worked.... weird how the behaviour is different on my own commandline and within bitbake... Oct 17 12:49:45 feilz: i rather guess that you misinterpreted something when doing it manually Oct 17 12:50:39 that the end result gets changed manually without -i, and when using the command through bitbake the end result doesn't get changed? Oct 17 12:50:43 wonder what I misinterpreted... Oct 17 13:10:16 feilz: sed without -i will read from the file and output the changes to the console Oct 17 13:10:28 but *won't write back* Oct 17 13:10:49 $ echo foo>test Oct 17 13:10:50 $ sed 's/foo/bar/g' test Oct 17 13:10:51 bar Oct 17 13:10:51 $ cat test Oct 17 13:10:53 foo Oct 17 13:16:27 rburton: CAT ABUSER! Oct 17 13:17:08 hey i didn't do cat|sed so no abuse here! Oct 17 13:17:49 i've got alternative facts there! Oct 17 13:28:56 hi, does anyone know if Go 1.13 support is being worked on in OE-core? Oct 17 13:30:11 rburton, nice, oe-pkgdata-util list-pkg-files glib-2.0 shows 5 DLL files and one EXE :) also glib-2.0-dev contains the correct files Oct 17 13:30:30 yay Oct 17 13:40:46 rburton: FOO := '${@bb.warn("help")}' ? Oct 17 13:42:44 RP: xvmc upgrade in next breaks the build Oct 17 13:43:07 khem maybe for you the Go question? (since you were the one upgrading 1.10->1.11->1.12) Oct 17 13:43:25 rburton: I thought that was dropped from next Oct 17 13:43:36 RP: ah maybe it sneaked into my mut with a rebase Oct 17 13:43:48 (needs a matching xorgproto bump which does't exist yet) Oct 17 13:43:48 rburton: I thought I replied on list and dropped Oct 17 13:43:57 oh. I thought that was the cat asking for help from rburton's abuse. Oct 17 13:43:59 RP: warn happens four times Oct 17 13:44:19 rburton: never happy Oct 17 13:44:57 :) Oct 17 13:45:17 rburton: its due to the fact the base config gets reparsed Oct 17 13:45:21 yeah Oct 17 13:49:29 RP: don't have the mails here, maybe i deleted them accidentally Oct 17 13:50:00 "accidentally" Oct 17 13:50:03 you forgot the quotes Oct 17 13:50:11 ha Oct 17 13:50:13 rburton: http://lists.openembedded.org/pipermail/openembedded-core/2019-October/287921.html Oct 17 13:50:27 * RP didn't imagine it Oct 17 13:50:35 i must have deleted it :) Oct 17 13:50:57 oh, ffs, i was filtering by sender Oct 17 14:14:33 qschulz, we have not official announced what thuds last dot release is. there are more out stands backports. maybe bug it Oct 17 14:14:35 personally, I would prefer if poppler would also make cairo optional. like the qt5 backend, cairo backend is optional in poppler Oct 17 14:14:46 and if one only uses the qt5 backend, cairo pulls in a lot of dependencies Oct 17 14:15:19 i will add a poppler bbappend and implement this Oct 17 14:18:25 armpit: ok, for me the N-2 release is EOL when N is out. So when Zeus is out, Thud is EOL. But maybe I'm assuming too much :D Oct 17 14:25:37 New news from stackoverflow: How to add own files in Yocto project Oct 17 14:40:36 litb: send a patch too! Oct 17 15:22:34 qschulz, we decided to revert the commit and re-spin Oct 17 15:22:47 RP, patch sent Oct 17 15:45:49 armpit: thanks, will trigger a build Oct 17 15:46:40 armpit: thanks a ton for taking care of this. Sorry for the mess Oct 17 15:47:07 qschulz: this is why I'm normally very nervous about taking these things... Oct 17 15:47:13 no worries. thanks for letting us know Oct 17 15:47:27 right, it is better to know Oct 17 15:55:08 I want to re-define a python function, how can I undefined it Oct 17 16:05:55 ^ simply redefine it in *.bbclass in a layer with higher priority Oct 17 16:23:47 Is it works for shell function too? Oct 17 16:27:08 bitbake variables are just key=value, bitbake functions are exactly the same as bitbake variables, just internally flagged as a function, and the only difference between a python and shell function is the presence of a 'python' flag marking it as python Oct 17 16:27:10 so yes Oct 17 16:28:32 is it possible to undefine an anonymous python function? Oct 17 16:28:52 or do you need to know the line number in which it was defined? I did notice that internally those are mangled with the line number Oct 17 16:29:23 not possible without poking into bitbake internals you should never poke into Oct 17 16:29:44 because.. overwriting an anonymous python function doesn't appear to be possible. 'python __anonymous() { ... }' will "append" automatically, I think Oct 17 16:29:45 of course, you could define your own anonymous pythgon function after that one that reverts what it does, if possible Oct 17 16:29:48 depends on the case Oct 17 16:30:05 correct, they're cumulative, and run in the order they're defined Oct 17 16:30:23 also, __anonymous is deprecated, just python () {} is preferred, but that's cosmetic :) Oct 17 16:31:06 hi - with rpm builds (on thud), has anyone seen failures due to "file /usr/share/polkit-1/rules.d conflicts between attempted installs of polkit-0.115-r0.aarch64 and systemd-1:239-r0.aarch64" ? Oct 17 16:31:44 the dirs look identical in the 2 rpms Oct 17 16:35:12 bluca: I think that's been seen a few times in some of the automated AGL builds, with a JIRA ticket assigned to me to try to figure it out, but I've not looked at it yet Oct 17 16:38:26 grr, go-runtime and other go.bbclass using recipes fail using the sourcery aarch64 toolchain, the sysroot and host cc arch aren't reliably passed to the linker Oct 17 16:38:27 hmm Oct 17 16:41:41 smurray - any tips for debugging? Oct 17 16:42:11 if I can find a solution I'll send a patch, as it's breaking my builds, but I'm pretty much fumbling in the dark Oct 17 16:42:34 bluca: sorry, not off the top of my head, no Oct 17 16:42:43 ok, thanks Oct 17 17:52:24 when a recipe sets USERADD_PARAM_, will the user be available when do_install() is ran? Oct 17 18:56:22 New news from stackoverflow: Building OpenDDS with bitbake Oct 17 19:41:16 hello folks Oct 17 19:41:44 does yocto support not having /usr , but that folders start with / ? i.e /bin, /lib etc? Oct 17 19:42:04 I found there's a usrmerge distfeature, but it's not followed everywhere in bitbake.conf ! some files are still put into /usr Oct 17 19:42:35 IMO when building for windows, the / and /usr merge doesn't make much sense Oct 17 19:42:45 s,merge,distinction, **** ENDING LOGGING AT Fri Oct 18 02:59:58 2019