**** BEGIN LOGGING AT Thu Sep 19 03:01:42 2019 Sep 19 06:59:32 So I'm trying to create a kernel+dtb+initrd inside a fitimage. In my machine configuration I have set KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPES += "fitImage". In my local.conf I have INITRAMFS_IMAGE = "my-initrd-image". This fails with a dependecy loop, where it seems like it tries to run "do_bundle_initramfs" even though I have not configured it to bundle the initramfs and kernel together. Sep 19 06:59:38 The only way to get around it is to comment out the INITRAMFS_IMAGE line, but then I won't get my initrd in the fitimage. Sep 19 07:07:05 iceaway: only thing that i can say ad-hoc is that we're using cpio.gz as the IMAGE_FSTYPE to bundle into fitImage Sep 19 07:07:22 marex-cloud: ^^^^^ you can probably tell us more. Sep 19 07:08:22 The dependency loops shouldn't be in recent oe versions Sep 19 07:08:37 LetoThe2nd: I'm using cpio.gz too for the initrd image recipe. I am on Yocto 2.5 if that matters. Sep 19 08:04:00 hello :) Sep 19 08:07:15 Hello All, is it possible add COMPATIBLE_MACHINE_append in a bbappend file. Sep 19 08:08:07 prabhakar: sure Sep 19 08:08:58 LetoThe2nd thank you Sep 19 08:13:29 LetoThe2nd how do we override a SRC_URI in a bbappend file I want to just change one location in bbappend, rest of the SRC_URI I would like to use the same as in original bb file. Sep 19 08:14:40 prabhakar: do you want to modify a location whcih is already there or add a new one? Sep 19 08:15:37 qschulz yes just the location of one source. Sep 19 08:18:10 prabhakar: you didn't answer the question :) modify or add a location? Sep 19 08:20:02 I want to modify Sep 19 08:20:16 what are you trying to do exactly? (the correct asnwer depends on your use case) Sep 19 08:22:09 qschulz I want to change the linux source location in the append file, but I want to reuse the other SRC_URI's pointed by the bb file Sep 19 08:22:52 prabhakar: it’s not pretty, but you can try to _remove the original uri and preprend the new one with =+ Sep 19 08:23:37 prabhakar: though if your use case is local development using externalsrc is a saner Sep 19 08:24:23 approach Sep 19 08:24:33 smurray: get behind me, sanity.. i mean, stan! Sep 19 08:24:40 satan, even. Sep 19 08:24:52 LetoThe2nd: heh Sep 19 08:26:30 LetoThe2nd: heh, the latest Periphery album is “HAIL STAN” ;) Sep 19 08:26:40 hrhrhr Sep 19 08:28:21 prabhakar: mmmmm are you sure you don't want to write a new recipe for that kernel instead? Sep 19 08:29:46 otherwise yes, _remove could work, but use the exact same line as the one in the original recipe with the variables not expanded/resolved but that's weird honestly Sep 19 08:30:31 Yes I dont want write a new recipe, I just want to change the source. Sep 19 08:31:56 hi there. i am currently starting to get used to yocto and tried building poky for that. now i've got a problem with one package, that i tried to fix, which was really nice to get in touch with devtool btw :) Sep 19 08:32:30 prabhakar, sry, i didn't see your original question, but you only wanne change sources? Sep 19 08:32:33 I don'[t understand the use case? I'd personally be not very happy if by adding your layer to my Yocto layers you modify where I get the linux kernel without changing anything in my conf files. Why do you need to change the source location? Sep 19 08:32:45 prabhakar, maybe check this wiki: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe Sep 19 08:33:23 prabhakar: If you control the original recipe, you could move that line (kernel location, I’m guessing) into a variable that you could override easier Sep 19 08:34:02 here is my problem, i don't understand: after pathing my sources i built the package directly using bitbake and everything works well Sep 19 08:34:28 BUT if i then again try to build the whole poky image (which hasthe package as a dep) that specific package fails again Sep 19 08:35:04 how can that be? i though building the specific package and building it as a dep of a whole image might run the same build process Sep 19 08:35:37 is there any mechanism that might influence the way that package got built during the image build? Sep 19 08:37:40 LetoThe2nd: do you happen to know if the parsing is parallelized? Sep 19 08:38:03 qschulz: nope, sorry. Sep 19 08:38:18 creich_: it’s hard to say, depends on what the failure is. I’ve seen that a few times, usually the recipe has an issue Sep 19 08:39:08 qschulz: that’s a question for RP, I can’t recall off the top of my head Sep 19 08:39:42 RP: then :) do you happen to know if the parsing is parallelized? Sep 19 08:41:48 and the reason for that question is: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/externalsrc.bbclass#n207 what happens if two externalsrc recipes are executing the same block starting at the line 207? Sep 19 08:42:20 smurray, hmm ok.. yeah, i just didn't want to waste your times by debugging that issue, since i tried to use yocto on an ARCH system, which is not oficcialy tested/supported Sep 19 08:42:46 it was more the question if it is possible, that the package could get built in twi different ways, which i wouldn't expect Sep 19 08:42:48 https://docs.python.org/3/library/tempfile.html#tempfile.NamedTemporaryFile then you go up the inheritance chain up to https://docs.python.org/3/library/tempfile.html#tempfile.mkstemp which says "If dir is not None, the file will be created in that directory; otherwise, a default directory is used. The default directory is chosen from a platform-dependent list, but the user of the application can control Sep 19 08:42:54 the directory location by setting the TMPDIR, TEMP or TMP environment variables." Sep 19 08:43:06 and... we have TMPDIR set which is a common one between all recipes Sep 19 08:43:48 the root problem was that my host gawk is to new (5.0.1) and was complaining about 'namespace' to be a keyword Sep 19 08:43:51 creich_: look at what's inside the image recipe and if it's not changing some variables in there? Sep 19 08:44:03 that happened when building libgpg-error Sep 19 08:44:53 i try to build libgpg-error on the branch yocto-2.7.1 Sep 19 08:45:10 bitbake core-image-sato --> fails Sep 19 08:45:21 bitbake libgpg-error --> works Sep 19 08:45:29 qschulz, thx, i am going to check Sep 19 08:53:07 qschulz: afaik that should be unlikely to be a problem, it would be different temp files as mkstemp generates unique names even when a prefix is given. As well, you’d need two recipes both specifying the same EXTERNALSRC value Sep 19 08:56:24 the only difference during build i can tell is that if i build the package directly, i ge ta notice 'NOTE: libgpg-error: compiling from external source tree /home/unknown/coding/yocto/poky/build/workspace/sources/libgpg-error' Sep 19 08:56:34 which i don't get if i try to build the image Sep 19 08:56:49 anyway to clean that up besides cleanall on the whole image build process? Sep 19 08:57:04 seems to me a problem with some cached stuff Sep 19 08:57:47 when building the package directly i could easily go and clean the related stuff using 'bitbake -c cleanall libgpg-error' Sep 19 08:59:00 smurray: True! Completely missed prefix= in the line in externalsrc! So, that one, unlikely, or if it ever happens an issue in Python itself.. Sep 19 09:00:24 creich_: did you do “devtool modify” or the like on it? That’s how it’d be trying to build it from there Sep 19 09:02:16 smurray, yes i did! that's intentional.. as i mentioned, i have gawk-5.0.1 which complaine about 'namespace' to be a keyword... but it's used inside one of the autoconf scripts of libgpg-error Sep 19 09:02:35 so i simple renamed it and tried to rebuild Sep 19 09:02:50 basically that is my first 'how to patch stuff' attemt Sep 19 09:03:23 after i tried building the lib for itself and everything looked good, i tried to continue building the image Sep 19 09:03:42 i am bulding poky for an raspi btw Sep 19 09:04:04 creich_: hmm, not sure why it not pick up that version in the image build, odd Sep 19 09:05:03 smurray: PREFERRED_PROVIDER/VERSION in some recipe? Sep 19 09:06:49 smurray, ok.. worst case would be a clean all and try to rebuild. but that might take a while Sep 19 09:09:33 ok, i guess i got it... it looks like there was some kind of 'variant' built.... libgpg-error-native Sep 19 09:10:06 i did not see that directly, since the error was pointing to libgpg-error (virtual:native was only written in front of smoe error message) Sep 19 09:10:21 and i though cleanall might clean all variants of the pacakge Sep 19 09:10:22 creich_: ok, try to build this one now but I'm pretty sure it won't build :) Sep 19 09:10:51 yep, that's what i think to ;) Sep 19 09:10:57 creich_: native packages (which are built for use on the host, so where Yocto is run) can be compiled differently Sep 19 09:11:03 can i get a list of all those variants? Sep 19 09:11:05 so cleanall wouldn't help much Sep 19 09:11:33 makes sence that they might be built differently Sep 19 09:11:59 creich_: wdym? there is -native, nativesdk- packages and then you have multilib (usually lib32- but can be something else) Sep 19 09:12:37 or should I say recipes instead of packages even though you can have all of the aforementioned one handled in the same recipe Sep 19 09:12:38 i jsut didn't see why 'bitbake libgpg-error' didn't build all of those variants Sep 19 09:13:07 ah ok, i start to ge it Sep 19 09:13:39 i can get the idea of one recipe building different packages... Sep 19 09:14:03 i am new to yocto, but i am an active gentoo user and used portage a lot Sep 19 09:15:37 creich_: you bitbake a recipe only (you also DEPENDS only on a recipe, but you RDEPENDS on a package (which can be named after the recipe)) Sep 19 09:16:33 those 'variants' come through the BBCLASSEXTEND, right? Sep 19 09:16:46 native, nativesdk and multilib are exceptions, you can bitbake them even though they don't have a recipe named after them Sep 19 09:17:02 creich_: for native and nativesdk yes, not multilib ones Sep 19 09:17:35 if i want to fix that variant (or is that even the right name?) i use devtool again, but on .. say 'libgpg-error-native' Sep 19 09:47:57 ok. now i know, that both variants can be fixed with the same bugfix. but i can not use devtool modify to modify both at the same time, since they are both based on the same recipe Sep 19 09:48:11 i guess i have to read more docu about how to go from there Sep 19 09:48:18 thanks a lot guys :D Sep 19 10:58:11 hello there. I'm using `thud` branch and using my `meta-toolchain` output on an Arch Linux machine. Sep 19 10:58:34 whenever I source sdk environment, I got this error: `Can't locate Time/HiRes.pm in @INC (you may need to install the Time::HiRes module)` Sep 19 10:58:55 can anyone, for the love of god and all holy angels and cat babies, help me? Sep 19 10:59:05 about to pull my last remaning hair folliciles Sep 19 11:04:07 cengiz_io: no need to be so cheesy. have you checked if perl is properly installed and working? Sep 19 11:04:23 cengiz_io: -> https://www.archlinux.org/packages/core/x86_64/perl/files/ Sep 19 11:06:32 LetoThe2nd why do you call me cheesy? I couldn't understand the reason Sep 19 11:06:53 10:58 < cengiz_io> can anyone, for the love of god and all holy angels and cat babies, help me? Sep 19 11:07:10 if that is not cheessy, i don't know how to call it, sorry. :D Sep 19 11:08:00 LetoThe2nd: that can be summed up as someone in desperate need of help. Sep 19 11:08:13 *sigh* anyways. did you check perl? Sep 19 11:09:34 $ perl -mTime::HiRes < works Sep 19 11:09:48 so I think my host machine's perl has Time::HiRes module Sep 19 11:10:18 perl (v5.30.0) Sep 19 11:10:49 but the toolchain has module skeleton for 5.24.4 ie: `/opt/fslc-framebuffer/2.6.3/sysroots/x86_64-fslcsdk-linux/usr/lib/perl/5.24.4/ ` Sep 19 11:11:09 can I be missing something in local.conf perhaps? Sep 19 11:11:10 cengiz_io: ok. any particular reason you're using meta-toolchain instead of an image-derived sdk? AFAIK, those are to be preferred, with meta-toolchain rather being a historic artifact Sep 19 11:11:31 LetoThe2nd didn't know that. Sep 19 11:12:07 I was just trying to get a toolchain so that I can give out to developers while I prepare the machine image. Sep 19 11:12:08 plus, https://community.nxp.com/thread/449585 Sep 19 11:12:22 they are compiling Qt apps to be run inside my image Sep 19 11:13:15 LetoThe2nd that last link is not relevant at all. it's for adding the modules *inside* the resulting image Sep 19 11:13:50 my error comes from using this `source /opt/fslc-framebuffer/2.6.3/environment-setup-armv7at2hf-neon-fslc-linux-gnueabi` Sep 19 11:14:27 it might still be necessary to manually add to the generated toolchain. (which would probably be a bug) Sep 19 11:14:39 but anyways, i'd really start with an image derived sdk Sep 19 11:14:46 cengiz_io: possbly a bug in meta-toolchain because its basically deprecated now. better to build a SDK from your image, (bitbake myimage -c populate_sdk) Sep 19 11:15:01 if a image sdk works, please file a bug for meta-toolchain Sep 19 11:15:06 didn't know that it's deprecated. Sep 19 11:15:26 cengiz_io: thats why we're telling you. Sep 19 11:15:28 does that image sdk add necessary files to my image tar.gz? Sep 19 11:15:45 it does not add anything to the image Sep 19 11:15:50 ok great Sep 19 11:15:55 bitbake -c populate_sdk YOUR_IMAGE Sep 19 11:16:04 thank you LetoThe2nd and rburton Sep 19 11:16:59 -> https://www.yoctoproject.org/docs/2.7.1/sdk-manual/sdk-manual.html Sep 19 11:17:05 lots of very good information! Sep 19 11:17:26 2.7.1? Sep 19 11:17:28 I need to compile tons of stuff by end of the day so I'm in a very bitter rush here. sorry for the misunderstandings Sep 19 11:18:09 rburton: first google hit, should be good enough Sep 19 11:27:52 * cengiz_io thinks things are getting even more confusing with eSDK Sep 19 11:28:11 * cengiz_io decided to print the relevant manual pages and read Sep 19 11:28:17 cengiz_io: then use the classic, conventional sdk, no problem Sep 19 11:46:57 Hey guys, I'm having a few issues running ruby (ruby native) inside a recipe. I noticed that I can call 'env ruby' inside devshell, but if I try to bitbake the recipe, ruby cannot be found. Sep 19 11:47:58 The PATH var has my host path included (/usr/bin, /bin...), but when I bitbake it directly, it doesn't (which is what I actually expected). Sep 19 11:48:23 Klanticus, IIRC devshell doesn't prune the environment, which bitbake does for scripts run from recipes Sep 19 11:49:05 Well, that explains the difference Sep 19 11:50:10 do you know how to find out why env is not locating ruby inside bitbake? Sep 19 11:50:30 Klanticus, do you have ruby-native in your DEPENDS ? Sep 19 11:51:08 Yeah, ruby-native is there and I have ' ASSUME_PROVIDED += "ruby-native"' on my local.conf Sep 19 11:51:54 Klanticus, hmm.. i'd assume youre not supposed to do both Sep 19 11:52:34 really? I want bitbake to just use my host's ruby. Isn't that the way to do it? Sep 19 11:53:58 Klanticus, I'd guess ruby-native in DEPENDS is not necessary then Sep 19 11:54:13 That's interesting... Let me try Sep 19 11:54:20 Klanticus, maybe you need to extend HOSTTOOLS Sep 19 11:57:15 yeah, had the same problem by just removing it from DEPENDS. I have now included ruby into HOSTTOOLS and it looked like it worked Sep 19 11:58:02 kroon: Do you know whether I have to keep it into ASSUME_PROVIDED too, now that it's in HOSTTOOLS? Sep 19 11:58:27 Klanticus, if you removed it from DEPENDS, id assume you don't need it in ASSUME_PROVIDED Sep 19 12:00:35 so adding it to HOSTTOOLS will make bitbake just hard link the system one into the sysroot, right? Sep 19 12:00:51 yeah Sep 19 12:03:37 kroon: looks like it worked now. Thanks a lot! The explanation about ASSUME_PROVIDED wasn't really clear to me Sep 19 12:05:14 Klanticus, you mean this one ? https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ASSUME_PROVIDED Sep 19 12:05:55 yeah.. "An example is git-native, which when specified, allows for the Git binary from the host to be used rather than building git-native." Sep 19 12:06:15 I thought it would just use the host ruby when I put it there Sep 19 12:06:28 Klanticus, yeah, I can agree, could use some improvement Sep 19 12:06:57 Klanticus, you can always improve it and send in a doc patch :-) Sep 19 12:07:39 As soon as I really understand it's meaning, I'll do it :) Sep 19 12:08:05 I'm a bit new in the Yocto world Sep 19 12:24:45 Does anyone have experience seeing poky/bitbake/lib/bb/data.py pick a different KERNEL_PROVIDER in the inheritFromOS method? Sep 19 12:27:26 It's only happening at one developer's desk. Sep 19 12:30:21 tgoodwin: some kind of ordering issue? Sep 19 12:30:56 tgoodwin: some python versions don't sort dict keys which leads to differences in behaviour. We do our best to avoid such problems but environment is one area we probably don't sort Sep 19 12:31:06 tgoodwin: totally guessing Sep 19 12:31:11 RP: I'm not sure...I'm trying to triage it and I can't reproduce it. It's like they accidentally set KERNEL_PROVIDER and KERNEL_TAG ahead of running bitbake. Sep 19 12:31:48 tgoodwin: those aren't standard variables so its hard for me to say... Sep 19 12:32:20 RP: I just had them start their terminal session and the vars are gone. /shrug/ Sep 19 12:32:28 I guess it was a PEBKAC. Sep 19 12:32:37 tgoodwin: sounds like it Sep 19 12:32:49 tgoodwin: its why we filter the env by default Sep 19 12:33:03 Right, but those two are whitelisted. Sep 19 12:35:05 tgoodwin: right, I'd guessed you were allowing them one way or another Sep 19 12:36:20 RP: It's interesting to get new folks onboard and see how things can go off the rails. Sep 19 12:36:45 I would love to see his bash history for that session. Sep 19 12:38:13 tgoodwin: I've seen lots of interesting things over the years :) Sep 19 12:41:04 cmake in yocto warrior.. terminate called after throwing an instance of 'std::logic_error' -- is this a known issue / how do I work around it? Sep 19 12:41:29 It seems to happen when it is attempting to generate the config Sep 19 12:41:30 fullstop: using cmake? on host? at build time? what recipe? Sep 19 12:41:44 rburton: on host, using cmake Sep 19 12:42:04 fullstop: all recipes using cmake, or just one? Sep 19 12:42:09 recipe is something that I'm trying to put together, but the package itself is dlib. This is not in any of the yocto / oe layers Sep 19 12:42:11 just this oen Sep 19 12:42:32 sounds like the cmakelists is broken in some way then if cmake works for all the other recipes Sep 19 12:42:46 well that's unfortunate Sep 19 12:42:54 libproxy or taglib are fairly easy cmake using recipes to test Sep 19 12:43:16 is there a way to enable extra verbose information from cmake so that I have a better chance of tracking it down? Sep 19 12:43:30 I know of one option which triggers it, so I can slowly narrow it down.. Sep 19 12:44:17 wow, --trace-expand is busy. :-) Sep 19 12:44:48 and doesn't actually show me anything useful after the crash. Sep 19 12:46:16 maybe try #cmake Sep 19 12:46:53 RP: Hmm, it was working a few weeks ago right? Sep 19 12:47:04 (Hash equivalence that is) Sep 19 12:47:18 JPEW: yes. Something is wrong but not sure quite where/what Sep 19 12:47:32 JPEW: its writing out two different hashes for the same task into locked sigs locally Sep 19 12:47:48 RP: Yuck. Sep 19 12:49:03 JPEW: My meta-sdk change is suspicous, as is Jaewon's esdk change but local reverts say they're ok Sep 19 12:50:29 RP: Ya. Do you think it would be worth while to try and write a test case that can reproduce that problem and then use it to bisect? Sep 19 12:51:38 My worry is that writing a test case that actually detects it might be difficult Sep 19 12:51:39 JPEW: I don't know. It can be very very hard to reproduce this kind of problem in a test case without knowing the root cause Sep 19 12:51:47 RP: Fair Sep 19 12:51:59 Hi. Does someone else have also problems to build a eSDK? Sep 19 12:52:31 ThomasD13: I'm talking about master-next and hash equivalence so problems you're unlikely to be hitting Sep 19 12:53:01 Okay :) Sep 19 12:53:01 JPEW: I just found its my meta-ext recipe change Sep 19 12:53:26 JPEW: which is clearly why it shouldn't be writing to sstate and it was designed that way Sep 19 12:54:36 JPEW: a revert is a preexisting build isn't enough Sep 19 12:58:36 Nevertheless: Could I ask a question regarding building eSDK with bitbake? During the build process I got an error: "ERROR: Failed to generate filtered task list for extensible SDK:" "Nothing provides 'xy' " Sep 19 12:59:21 Package 'xy' is defined in layer "meta-ibg". A few lines above I noticed this output: "NOTE: Excluding local workspace layer /home/ewtd/poky/meta-ibg from extensible SDK" Sep 19 13:00:12 I looked at the python code, and it's getting excluded, because the first line of the layer.config matches with ""# ### workspace layer auto-generated by devtool ###" Sep 19 13:01:09 So, is the right way to change this line, that the layer does not get excluded anymore? Sep 19 13:03:05 ThomasD13: nope, the problem is probably that your layer is located beneath poky, which is a bad practise Sep 19 13:04:47 LetoThe2nd this is my structure: https://pastebin.com/X58qHkhT Sep 19 13:05:10 "meta-ibg" is my layer. I thought that would be the right place? Sep 19 13:06:08 ThomasD13: well... actually i find the constealltion pretty bad. Sep 19 13:06:28 ThomasD13: your build is inside poky, for example Sep 19 13:07:22 <__angelo> hi, adding package "zip" but for some reason bitbake -g is not carching it .. Sep 19 13:07:29 ThomasD13: i always recommend something like https://pastebin.com/g1pP2f8A Sep 19 13:09:00 LetoThe2nd okay. I'll try to fix that. Do you really think thats the cause for my problem? Sep 19 13:09:15 ThomasD13: i at least guess it. no guarantees. Sep 19 13:10:08 ThomasD13: have you tried removing that line about "being auto-generated" Sep 19 13:10:44 ThomasD13: if its become a layer in its own right its probably not needed/appropriate any more? Sep 19 13:10:58 LetoThe2nd: I'm just wondering. I cloned poky and started working with the given structure. So I have to move all the layers to the outside of poky first? Sep 19 13:11:33 btw, does anyone fancy a "simple" optimisation issue to work on: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 ? Sep 19 13:11:34 Bug 13539: enhancement, Undecided, ---, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK Sep 19 13:11:38 ThomasD13: well thats what i do and recommend, because that way you get a clean structure for SCMs Sep 19 13:11:44 RP: Yes I did. Then I get different errors (thousand of red lines) but I didn't worked through yet. Just wanna ask before, if that would be the right way Sep 19 13:12:13 ThomasD13: its where I would have started but LetoThe2nd may be right about structure too Sep 19 13:13:50 Okay thanks guys. I try to relocate the directories and see if that solves my issue Sep 19 13:18:16 hej :) Sep 19 13:18:48 What happens if, say, I want to change the default /etc/network/interfaces? Do I write a new recipe just to copy the file in the right place? Or is there another mechanism for that? Sep 19 13:19:10 palate: usually an append that includes the file in SRC_URI Sep 19 13:28:30 LetoThe2nd: right, but in this case /etc/network/interfaces doesn't come with a package of mine, right? So I just make an "empty" recipe that appends only the file? Sep 19 13:30:41 palate: you have a .bbappend with FILESEXTRAPATH_prepend := "${THIsDIR}/files:" and you put your interfaces at the same place in "files" dirs that in the original recipe Sep 19 13:31:35 ok, let me check that Sep 19 13:31:52 which AFAICT, is directly in "files" Sep 19 13:32:43 the FILESEXTRAPATHS magic will then do its work, you need one line in the bbappend and the interfaces file in the dir you put in FILESEXTRAPATHS Sep 19 13:38:55 JPEW: even with that reverted the esdk tests fail with hash mismatches Sep 19 13:39:51 RP: Did reverting it fix the other failures? Sep 19 13:40:04 JPEW: yes, but there is the original problem that patch was for Sep 19 13:41:07 RP: Ok. I'm not terribly suprised that hash equivalence messes with the eSDK, they both are trying to do related things. I'll run the tests locally to see if I can dig into it. Sep 19 13:41:41 RP: Do you have a link to the failed test handy? Sep 19 13:44:27 JPEW: I was reproducing locally with a "bitbake core-image-sato -c testsdkext" for qemux86-64 Sep 19 13:44:47 JPEW: I don't have an online link for the exact failures there are a lot of different things on the autobuilder :( Sep 19 13:45:05 RP: OK, all I really wanted was how to start the test Sep 19 14:35:31 Some basic question: Whats the difference between branches warrior and warrior-next? Sep 19 14:48:14 -next for any branch is the staging area for new patches Sep 19 14:48:37 patches in it may be altered, removed, etc. when theyre all good, merged to warrior Sep 19 14:48:44 ditto for master vs master-next, etc Sep 19 14:50:03 alright, thank you rburton Sep 19 15:01:40 Trying again earlier today, maybe my question will catch the attention of more people :) I'm debugging an issue with symlinks to dirs used in SRC_URI where file://symlink-dir does not work but file://symlink-dir/ works. Sep 19 15:02:31 in the first situation, file-checksums is empty, but in the second, it is correctly set. So I'm trying to understand where and how this file-checksums is set Sep 19 15:10:37 Hello again LetoThe2nd I've build the populate_sdk_ext just to make sure I get everything, does it have to be in the same machine as my yocto build system? Sep 19 15:10:52 because it contains hardcoded paths to it Sep 19 15:11:14 according to the docs you've sent, sdk can be on different machines.. isn't that the whole point? Sep 19 15:12:03 LetoThe2nd: `FSLC FrameBuffer Extensible SDK installer version 2.6.3` to be exact Sep 19 15:12:14 built* Sep 19 15:15:14 cengiz_io: no, you should be able to take and install it anywhere, as long as the prerequisites are all installed Sep 19 15:15:48 so I have x86_64-buildtools-nativesdk-standalone-2.6.sh and fslc-framebuffer-glibc-x86_64-MACHINENAME-base-image-armv7at2hf-neon-toolchain-ext-2.6.3.sh Sep 19 15:16:13 nativesdk-standalone seems to be installed in /opt/ by default Sep 19 15:16:38 that both sounds strange. Sep 19 15:17:07 let me check Sep 19 15:17:12 MACHINENAME-base-image is my image name, consored by me :) Sep 19 15:17:37 * cengiz_io enterprise problems.. Sep 19 15:38:18 <__angelo> getting this error on postinst scrplets "systemctl: error: argument command: invalid choice: 'disable' (choose from 'enable', 'mask', 'preset-all')" Sep 19 15:39:32 rburton: seems to be a cmake bug with respect to cuda and at which level enable_language(CUDA) is called. Sep 19 15:39:52 fun! Sep 19 16:09:06 cengiz_io: so, i just verified: if you do a populate_sdk on an image, the resulting name should be something like poky-glibc-x86_64-IMAGE_NAME-TUNE-MACHINE-toolchain-2.7.1.sh Sep 19 16:09:18 cengiz_io: located under tmp/deploy/sdk Sep 19 16:09:58 ah, now i got it. the first part is the distro, and yours probably is "fslc-frambuffer" Sep 19 16:10:02 yes, then it makes sense **** BEGIN LOGGING AT Thu Sep 19 17:59:14 2019 Sep 19 18:52:24 fullstop: sometimes qemu is used to do things that have to be done on the target arch. i think fontconfig uses it, for example Sep 19 18:53:00 hmm Sep 19 18:53:21 I wonder if glib does as well. That package does not like to be cross compiled. Sep 19 19:26:35 Hey, we are using an EXTERNAL_TOOLCHAIN, but when we build the SDK, the path to the external toolchain is not in the "environment-setup*" file, but the programs such as CC do not contain paths so then the environment can't find the tools Sep 19 19:26:48 fullstop: glib cross-builds fine Sep 19 19:28:09 rburton: I'll have to check out the recipe. When I tried it, a while ago and without yocto, it required specifying stuff in some .cache file because it wanted to build tools to discover attributes about the target system.. but it tried to run those natively. Sep 19 19:32:32 ah, it uses meson Sep 19 19:50:40 nevermind, it looks like the environment script is generated by toolchain-scripts.bbclass, and it's not meant to be extended Sep 19 19:54:22 JPEW: could you reproduce out of interest? Sep 19 19:58:24 how the heck do i pass extra cflags to a kernel build? Sep 19 19:59:55 RP: Got side tracked by my day job, I'll retry overnight Sep 19 20:00:15 JPEW: fair enough :) Sep 19 20:00:26 JPEW: I can't even get bugs to reproduce :/ Sep 19 20:00:47 mischief, the kernel generates its own flags. so you'll need to patch things. there's no flow of whatever userspace is using -> the kernel build. You can do somethings via the CC=, etc, but it is kludgey Sep 19 20:03:23 argh, okay Sep 19 20:04:17 i have a warning about duplicate const in this vendor code, but it seems to only abort the build because of Werror Sep 19 20:04:30 i thought i could just turn off the duplicate const warning but i guess ill just make a patch. Sep 19 20:33:48 kanavin: not sure if https://bugzilla.yoctoproject.org/show_bug.cgi?id=13539 would interest you or not? Sep 19 20:33:49 Bug 13539: enhancement, Medium+, 2.8 M4, paul.eggleton, NEW , eSDK: performance issues when assembling sstate for full SDK Sep 19 20:37:09 Does this seem unexpected to anyone? FOO ?= "a" FOO_someoverride_append = "b" (Foo is now "b") Anyone know why bitbake works this way? Sep 19 20:37:41 And if you remove "_someoverride", then Foo is "ab" Sep 19 20:38:43 I think if you originally set FOO = "a", it's the same thing as well Sep 19 20:38:49 marler899722: not unexpected Sep 19 20:38:58 marler899722: it expands RHS first Sep 19 20:39:21 so FOO_someoverride_append = "b" becomes FOO_someoverride = "b" Sep 19 20:39:32 that's not what's unexpected Sep 19 20:39:42 it's that it ignores the non-override set Sep 19 20:39:59 but if you're append deosn't have an override, then it uses the non-override set Sep 19 20:40:44 marler899722: so for FOO = "a" FOO_someoverride = "b" what do you expect? Sep 19 20:41:02 "b" Sep 19 20:41:14 right Sep 19 20:41:21 oh Sep 19 20:41:31 so if it was FOO_append_someoverride, then what would it be? Sep 19 20:41:49 that is quite different Sep 19 20:41:55 ab Sep 19 20:43:01 trying to wrap my head around that... Sep 19 20:44:03 ok I think I get it Sep 19 20:44:20 thanks for the help Sep 19 20:44:20 it's a common source of confusion, but provides a fair bit of flexibility. iirc we highlight that at least somewhat in the bitbake manual. Sep 19 20:44:24 there it is, https://www.yoctoproject.org/docs/2.0/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples Sep 19 20:44:53 thanks for the link, will read Sep 19 20:45:02 np Sep 19 20:45:19 marler899722: I try and process these things reading from the right hand side which is also what bitbake does Sep 19 20:45:38 yeah, thinking of it as RHS first is a good idea, easier to grasp. good call Sep 19 20:45:43 yeah it makes more sense when I think of it that way Sep 19 20:45:51 wonder if we sould mention that specifically int he docs Sep 19 20:46:11 kergoth: could be an idea Sep 19 20:57:39 Ok, what do you think this one will do? OVERRIDES = "foo" A = "1" A_append = "2" A_append_foo = "3" ??? Sep 19 20:58:01 123 Sep 19 20:58:31 should be 123 as appends stack Sep 19 20:58:48 so you can't "override" an append Sep 19 20:58:48 If you want 13, use OVERRIDES = "foo" A = "1" A_append = "${BAR}" BAR = "2" BAR_foo = "3" Sep 19 20:59:42 Could have fooled me today as well, I seriously doubted for a second whether A_remove = "a" A_remove = "b" did even make sense Sep 19 20:59:47 based on what I read in that section, I think this case also deserves an explanation Sep 19 21:00:28 marler899722: a patch would be most welcome Sep 19 21:01:01 ugh, sending patches is difficult for me as I'm behind a proxy and git send-email doesn't work behind a proxy Sep 19 21:01:19 marler899722: maybe file a bug then with the suggested change? Sep 19 21:01:31 I could do that Sep 19 21:01:37 it's on my todo Sep 19 21:01:49 Stupid question, though -- why don't you just socat (or whatever tunneling utility you use) your SMTP port through the proxy and configure git to connect to that instead? Sep 19 21:02:22 I do use socat Sep 19 21:02:34 that's how I can push fetch git repos outside our network Sep 19 21:02:41 but git send-email ignores the proxy settings Sep 19 21:03:20 well, but can't you just start a socat in one terminal to proxy localhost:4567 to smtp.gmail.com:587 and configure git send-email to use localhost:4567 as smtp? Sep 19 21:03:52 hmmmm, might work, though I don't know if SMTP has any host headers that would need to be fixed Sep 19 21:04:54 it does, but you might get away with putting 127.0.0.1 smtp.gmail.com into your /etc/hosts Sep 19 21:05:01 oh geeze Sep 19 21:05:21 yes that would certainly work Sep 19 21:05:55 I don't think I can bring myself to do it though...just seems so wrong Sep 19 21:06:37 marler899722: it can't be worse than one setup I was forced into that had firefox running as root to run a java app that did individual port forwarding Sep 19 21:06:38 what seems wrong is your proxy or your inability to use company email to contribute, if you ask me... Sep 19 21:07:10 so you do what you must, and we've all been there at one point or another :/ Sep 19 21:07:31 neverpanic: indeed Sep 19 21:08:20 true, but I weight that janky setup with how much pain do I want to put myself through just to get simple patches into yocto Sep 19 21:09:12 I contribute to hundreds of projects and I can't keep track of the janky setup for each one...I have to pick my battles in that case Sep 19 21:10:56 marler899722: perhaps the bugzilla then? Sep 19 21:11:11 yes, creating issues on bugzilla is fine Sep 19 21:11:35 I suppose I could put a patch in there too? Sep 19 21:11:54 marler899722: yes, just mention you can't send to the list due to firewall issues Sep 19 21:12:26 marler899722: it means someone else will need to send for you (probably me) but its better than just forgetting the issue Sep 19 21:12:39 cool I will keep that in mind Sep 19 21:12:51 marler899722: I'd look at the docs now but I'm in the middle of other stuff and have other problems :( Sep 19 21:13:50 speaking of patches, I sent one out 3 days ago manually from my gmail account. I'm not sure if it got sent to the mailing list properly, can anyone confirm? Subject is [OE-core] [PATCH 0/1] Assert error when there are multiple shlib_providers for the same file Sep 19 21:14:38 marler899722: you can extend the sdk environment script in multiple ways. the easiest is to just install a script fragment into one of the sysroots. that is, create a recipe that installs an extra script that the env setup will source. Sep 19 21:15:04 how do I change the env setup script to source it? Sep 19 21:15:25 there's an example of that right in meta-external-toolchain Sep 19 21:15:38 you don't need to. the main one already sources anything in environment-setup.d/ in the sysroot Sep 19 21:15:41 https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-sdk/sdk-env-external-toolchain/sdk-env-external-toolchain.bb Sep 19 21:15:56 oh Sep 19 21:16:08 all you need is a recipe/package to install the fragment there Sep 19 21:16:10 like the above Sep 19 21:16:50 marler899722: the 0/1 patch header came through, the patch was not there as a following 1/1 Sep 19 21:17:23 yeah I was told to just send the cover-letter, and people could look at the github link to see the patch Sep 19 21:17:54 So environment-setup.d must be special? Does the recipe need the "-toolchain" suffix? Sep 19 21:17:56 yeah that was my suggestion, since they can't use send-email directly, and gmail will mangle it otherwise Sep 19 21:18:03 no, recipe name can be anything Sep 19 21:18:54 So you must just add that to TOOLCHAIN_TARGET_TASK? Sep 19 21:19:08 https://github.com/openembedded/openembedded-core/blob/e38e56e28f2090e2b8013546f4dd76da8d59f766/meta/classes/toolchain-scripts.bbclass#L106 Sep 19 21:19:38 yep, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/conf/distro/include/tcmode-external.inc#n35 Sep 19 21:19:42 awesome Sep 19 21:20:36 it pulls the scripts from either the target or nativesdk/native sysroot actually, so can have a recipe for either one, depending on what variables you need to access in the metadata, if any Sep 19 21:20:49 marler899722: A note saying there would be no 1/1 would have helped as I assumed it would come later (it never did) Sep 19 21:20:50 most cases it won't matter, though Sep 19 21:21:11 RP: will remember that for next time Sep 19 21:24:12 marler899722: looking at your patch it won't apply to master as there are other changes in that area. Normally we'd put sorted() around the .keys() to at least make this deterministic Sep 19 21:24:24 marler899722: its looks like a valid bug though Sep 19 21:24:37 yeah that's one way to fix the determinism Sep 19 21:25:08 although, I think going one step further to assert an error with multiple would be better Sep 19 21:25:08 marler899722: initially I was thinking it was related to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=41a5dbd16b0c9f5f97e7a160830cf7ca5de52ec6 Sep 19 21:25:26 marler899722: yes, I'd probably bb.error, not fatal though Sep 19 21:25:46 sounds reasonable Sep 19 21:26:36 changed Sep 19 21:28:22 marler899722: for completeness, the commit short log needs to start "package:" to give people an idea of the area of code it touches and I'd remove the word "assert" as that means something very specific in python that doesn't apply here. Can you rebase it against master? Sep 19 21:28:27 Isn't it kind of a bad habit to have more than one shlib provider for the same lib anyway, though? Sep 19 21:28:49 neverpanic: yes, showing an error would therefore be good Sep 19 21:28:57 Can do Sep 19 21:30:07 Right, but shouldn't http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/package.bbclass#n1788 be turned into an error then? Sep 19 21:30:53 rebased and fixed commit message Sep 19 21:33:16 marler899722: sorry, one more thing. Can we add a sorted in there please so it is deterministic :) Sep 19 21:33:36 that would only affect the determinism of the error message Sep 19 21:33:46 do you still want it? Sep 19 21:34:53 marler899722: The error will flag the exit code and trigger CI failure but keep building so yes please Sep 19 21:35:15 ok, changed Sep 19 21:35:28 (we do that so that you get a list of failures rather than a dead build which you restart then get the next issue) Sep 19 21:35:41 ah, that's why you wanted bb.error Sep 19 21:35:54 Its just in keeping with the rest of the code Sep 19 21:36:51 marler899722: thanks, I'll queue that. I'll have to send for mailing list patch review Sep 19 21:37:28 thanks Sep 19 21:49:14 hi Sep 19 21:49:55 I have some Makefile based binary and this project setup CFLAGS but CFLAGS gets overwritten by yocto CFLAGS is there way how to suppress this? Sep 19 21:52:18 ideally the Makefile would be fixed to append to whatever flags Yocto provides in the environment Sep 19 21:52:43 Unexpected things can happen when build systems ignore the flags Yocto wants them to use Sep 19 21:55:13 CFLAGS in a makefiel should never be overridden by cflags in the environment unless the makefile uses ?=, or you have -e in EXTRA_OEMAKE Sep 19 21:56:18 kergoth: I have this in recipe: EXTRA_OE_MAKE = "CUSTOMER_VERSION=COMMON1 V=1" Sep 19 21:57:01 it's EXTRA_OEMAKE, not EXTRA_OE_MAKE, but if that's the case, the cflags ij the environment shouldn't be overriding the makefile unless the makefile explicitly allows it through use of ?=. Sep 19 21:57:27 but looking at run.do_compile it adds automatically adds: make -j 12 -e MAKEFLAGS= Sep 19 21:58:46 kergoth: Makefile use: CFLAGS += -Wall -g Sep 19 22:01:00 that's becuase you didn't set EXTRA_OEMAKE. Sep 19 22:01:09 if you did, it wouldn't append -e MAKEFLAGS=, that's the default value of EXTRA_OEMAKE Sep 19 22:01:25 like i said, it's EXTRA_OEMAKE, not EXTRA_OE_MAKE :) Sep 19 22:02:33 kergoth: yes you're right Sep 19 22:02:58 the -e argument is causing your issue, it tells make to let the environment override vars in files Sep 19 22:03:08 not I get CFLAGS from Makefile but CFLAGS from yocto are lost (I would need at least sysroot) Sep 19 22:03:21 sysroot isn't in cflags, it's in cc Sep 19 22:03:35 and it shouldn't be lost if it's using +=, that means append, not set Sep 19 22:04:01 if you're going to override EXTRA_OEMAKE, you really need to explicitly pass every variable in Sep 19 22:04:12 well, not always, but usually Sep 19 22:04:20 since most mkakefiles don't use ?= for vars like CC Sep 19 22:04:37 so you'd want to do i.e. 'CC=${CC}' in your EXTRA_OEMAKE, along with any other vars it will obey Sep 19 22:04:42 kergoth: yes sorry you're right CFLAGS are OK (ones from Makefile + from yocto) Sep 19 22:04:47 you have to read the underlying makefiles to know what it obeys in what contexts Sep 19 22:04:52 fatal error: stdio.h: No such file or directory Sep 19 22:04:52 | #include Sep 19 22:05:02 this is the downside to using custom amkefile based buildsystems, there's no standards, it's case-by-case Sep 19 22:05:02 but it drop sysroots path Sep 19 22:05:10 yeah, it's not obeying CC Sep 19 22:05:18 should I pass somehow sysrootfs? Sep 19 22:05:26 again, it's in CC Sep 19 22:05:48 grep for CC= or EXTRA_OEMAKE in oe-core, you'll find some recipes with examples of passing such variables in EXTRA_OEMAKE Sep 19 22:06:27 TBH, unless it's more than 20 source files, probably faster to write a simple CMakeLists.txt instead ¯\_(ツ)_/¯ Sep 19 22:06:38 ok adding CC=${CC} I move forward Sep 19 22:06:54 but then again : s.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory Sep 19 22:07:55 neverpanic: it's proprietary binary for chinese camera and reading those makefiles I probably will bump my head to wall many many times :) Sep 19 22:08:07 just want ot make it compilable by yocto and I win :D Sep 19 22:08:29 Ah yes, been there, seen that. My condolences :/ Sep 19 22:09:06 you'll need to cover all the usual suspects, variable wise. cc alone won't do. you need anything it's using. cc, cflags, ldflags, ld, etc Sep 19 22:10:17 or you leave the -e in and hope it doesn't blow away anything required, and also that the variable names are the same, which isn't always the case Sep 19 22:10:50 yay plain makefiles Sep 19 22:11:34 I'll start thinking about rewriting it in cmake :) Sep 19 22:11:35 ugh. as much as i dislike autoconf, i'd rather that that something homerolled, anyday. Sep 19 22:12:21 what's your take on meson vs cmake? Sep 19 22:12:29 meson seems pretty usable and gets things right Sep 19 22:12:58 I've contribued to CMAKE, and the parts had to touch were quite ugly Sep 19 22:13:01 CMake tends to have awkward syntax and its "standard library" isn't really very helpful in some cases Sep 19 22:13:37 yeah.. i can't say i enjoy working with cmake at all Sep 19 22:13:44 Modern CMake is actually quite nice too, but people don't conistently use targets, and once you've moved into things that aren't properly set up as targets, you'll be in a world of pain :/ Sep 19 22:14:01 yeah, I think you can do CMAKE well if you know what you're doing Sep 19 22:14:10 I think cmake is better like ninja :) Sep 19 22:14:34 https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ comes to mind Sep 19 22:14:36 https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ is the best how-to I've found so far. If you do CMake and follow that, you'll be fine. Sep 19 22:14:37 opennandra: what's better? Sep 19 22:14:39 ha :) Sep 19 22:14:42 kergoth: ha! Sep 19 22:15:29 marler899722: meson is awesome use meson Sep 19 22:15:47 I have hard times when hacking somethign in google-chrome to understand all those dependencies in ninja file. I worked for quite some years with cmake (nothing special) but I really like it Sep 19 22:16:19 meson also uses ninja Sep 19 22:16:44 I don't have anything against generated ninja (as it compiles) Sep 19 22:20:12 other thing I want to ask I want to use external toolchain (linaro 4.9.4), it's enough to pull meta-linaro and change TCMODE in local.conf? I plan to use it wil older poky as with latest it cannot compile with such toolchain Sep 19 22:20:54 usually you also need to set EXTERNAL_TOOLCHAIN to the toolchain path Sep 19 22:20:56 I'm compiling thud with linaro Sep 19 22:21:00 but that's probably enough Sep 19 22:21:05 see the layer readme, really.. Sep 19 22:21:30 compiling thud with linaro version 7.3 and 7.4 Sep 19 22:21:31 ok cool thanks Sep 19 22:21:36 I'll give a shot Sep 19 22:23:16 marler899722: what advantage does the linaro toolchain have out of interest? Sep 19 22:24:52 Apparently it has more arm-specific optimization Sep 19 22:25:37 marler899722: I see, was just curious Sep 19 22:25:40 I'd be interested in a comparison with a modern clang-based toolchain. I'd figure Apple has put some serious work into their ARM backend. Sep 19 22:25:53 yeah that would be good to see Sep 19 22:25:57 I need to stick to linaro as SDK I'm integrating in yocto was compiled with 4.9.4 linaro toolchain (I tried to compile with poky toolchain 7.3) but kernel fails to build as it's some chinese vendor 3.18 with lot of assembly so I have to stick with linaro (also use poky jethro where 4.9 is available) Sep 19 22:26:19 neverpanic: As has ARM, as has Google, and many others. Sep 19 22:26:32 so currently use one from poky but in final I want to use linaro Sep 19 22:26:37 just to be on safe side :D Sep 19 22:27:12 you say "poky", but which yocto branch are you on? Sep 19 22:27:17 And the last time I looked at some assembly output of the linaro toolchain for debugging (granted that was years ago), there was obvious optimization potential Sep 19 22:27:29 poky jethro Sep 19 22:27:30 I think it was setting a register that it xor'd with itself right after Sep 19 22:28:25 anecdotal, but I'd expect that would be a pretty simple optimization Sep 19 22:30:59 world has changed a lot since jethro :/ Sep 19 22:32:59 RP: yes this is true Sep 19 22:37:53 JPEW: I think there is a fix for the esdk issue in -next Sep 19 23:44:28 * armpit when does -next become -whenever ?? ; ) **** ENDING LOGGING AT Fri Sep 20 02:59:57 2019