**** BEGIN LOGGING AT Wed Jan 22 03:01:07 2020 Jan 22 05:30:52 zeddii, have you seen this fix? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/mips?h=v5.4.13&id=520e3bd3dee4266603b97ad5f5cedb88736a09c5 Jan 22 07:10:11 Hi, I have some problems to build sucessfully a recipe. The recipe "A" configures/builds/install a cmake project. The cmake project consists of shared library "B" and application "C". "B" is linked to "C". Jan 22 07:11:54 ThomasD13: i take it that you have already watched https://youtu.be/IehnEC3GOGU ? Jan 22 07:12:01 When I build this cmake project here, I have no problems. When I build the recipe with yocto, I got an error during do_compile: https://pastebin.com/2uWsZTuN Jan 22 07:13:27 LetoThe2nd, no I did not yet. I watched the first two, and the 7 or 8. video from you Jan 22 07:13:47 ThomasD13: its covering the very exact situation that you have. cmake project, which builds a lib and an application, both to be packaged seperately. Jan 22 07:13:55 However, Yocto says it cannot find "rfal_lib" which is "B" in my example Jan 22 07:14:27 ThomasD13: no, its not yocto saying that. this is cmake barfing out on you getting the linkage wrong Jan 22 07:14:41 ThomasD13: check against https://github.com/LetoThe2nd/libanswer Jan 22 07:14:51 LetoThe2nd, okay - That was my question now: So its basically a problem to provide a package which has only "internal" dependencies? Jan 22 07:15:12 please see video :) Jan 22 07:15:18 alright ;) Jan 22 07:18:53 ThomasD13: in addition to LetoThe2nd's suggestion about the video, you might want to share the CMakeLists.txt too. And when you build locally, do you use parallel make? Jan 22 07:44:01 erbo, locally I just invoked "make". So nothing parallel. This is for "B" (rfal_lib): https://pastebin.com/XDSrkKww This is for "C": https://pastebin.com/AYrAAM34 Jan 22 07:46:32 Without viewed LetoThe2nd videos, I might think the problem could be, that cmake does not install rfal_lib systemwide. My preference would be that the lib stays locally near to executable. But I think I will try that at first to install library systemwide Jan 22 07:46:46 And then watch the video ;) Jan 22 07:47:45 ThomasD13: then how could the package in the video build? during the linking stage, cmake is totally unaware of any form of installation whatsoever. Jan 22 07:48:20 so my first and foremost guess is that your library dependencies inside CMakeLists.txt are off. Jan 22 07:54:09 LetoThe2nd, I cannot answer this yet. I need to watch video first. My thoughts are: How could be the library dependencies inside CMakeLists are off, if it builds fine without yocto Jan 22 07:54:25 I agree with LetoThe2nd, this is most likely a CMakeLists issue Jan 22 07:55:09 Don't get me wrong, I hope also this is a CMakeList problem. I guess thats much easier to fix as something with yocto Jan 22 07:55:10 ThomasD13: Since you didn't use parallel make, maybe you're lib is always built before the app. Jan 22 07:55:35 s/you're/your/ Jan 22 07:55:49 erbo, I think the lib must be built before the app, since it's linked to it Jan 22 07:56:05 ThomasD13: of course, but did you state that in the CMakeLists file? Jan 22 07:58:28 You can try building the recipe without parallel make by disabling it in the recipe: PARALLEL_MAKE = "" Jan 22 07:58:58 But I suggest you don't use that as a solution, better to solve it properly, but it could help verify that this is the issue Jan 22 08:00:19 erbo, thats a good point. I thought I have this done with target_link_libraries(). I just digging into cmake documentation. Thanks for the hint with PARALLEL_MAKE. And thanks LetoThe2nd for your great videos ;) Jan 22 08:00:22 ThomasD13: do you have a top-level CMakeLists which uses the other two? Jan 22 08:01:17 erbo, this is it: https://pastebin.com/v9WT8abB Jan 22 08:04:45 ThomasD13: I'm no CMake expert, but I think something like "add_dependencies (exampleNFC rfal_lib)" in the apps CMakeLists might solve it Jan 22 08:05:24 erbo, I'll check that, thank you very much. Jan 22 08:45:33 LetoThe2nd, just curious about your libanswer (https://github.com/LetoThe2nd/libanswer/blob/master/CMakeLists.txt): You linked answer to your application ask. Did you specify in the recipe RDEPENDS = libanswer.so or something? Or might this be answered in that video? Jan 22 08:50:38 ThomasD13: i don't exactly remember. but pretty sure i did not. RDEPENGing on a library is almost certainly a bug (i mean, how could you get through build time if its a runtime dependency only?) Jan 22 08:52:26 Okay, because I fixed the cmake-problem that the compile stage works. Now I got some QA Issues. I'll do some google research to better understand the problem Jan 22 08:53:34 ThomasD13: let me guess. you didn't bother to actually understand the problem, and now you're randomly copy-pasting in things that you found on stackoverflow? Jan 22 08:54:46 and yes, QA things are to be taken *SERIOUSLY* unless you know exactly what caused them, and can properly judge that its false positives. Jan 22 08:57:50 LetoThe2nd, I understand now the first problem at the compile stage. It was a cmake misconfiguration. Now I got the next problem during QA stage. My CMakeList looks similar to yours, thats why the question if you specified RDEPEND in your recipe. And thanks for the picture of me to randomly copy&paste from so ;) but guess: No I try to understand the problem and dont want to steal your time with this simple question. Thats Jan 22 08:57:50 why I want to google first Jan 22 08:58:48 https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-qa-checks Jan 22 08:59:17 ThomasD13: you are stealing time not because of googling. you are stealing time because of "some QA issues" instead of "i am seeing QA issue XYZ". because if you had just named your issue, you would probably have gotten a pointer real quick. Jan 22 09:00:26 ThomasD13: and if you want to find out what i specified, jsut watch the video. feel free to skip. its just what i would have to do in order to find out. Jan 22 09:26:36 New news from stackoverflow: Yocto packagegroup install Jan 22 09:40:29 session #10 uploaded 12hrs ago, already >60 views on YT Jan 22 09:40:36 * LetoThe2nd enters full rockstar mode! Jan 22 09:43:41 LetoThe2nd: time for a promotion to LetoTheGreat? :) Jan 22 09:44:07 nrossi: i am already god emperor of the known universe. hard to be promoted any further. Jan 22 09:44:27 LetoThe2nd: last yocti message: isn't it the same thing as yesterday? i.e. CORE_IMAGE_EXTRA_INSTALL and not IMAGE_INSTALL? Jan 22 09:44:35 LetoThe2nd: time to expand to the multi-verse :) Jan 22 09:44:50 nrossi: hehe Jan 22 09:45:02 qschulz: no iea. Jan 22 09:48:49 LetoThe2nd: I sent a comment, we'll see :) Jan 22 10:16:42 qschulz: I think it looks correct, but I also added a comment with an idea Jan 22 10:50:15 erbo: mmm good point as well, I always forget about this renaming of packages if they only contain a lib Jan 22 11:11:45 qschulz: if you think about my question from yesterday, when i couldn't build the executable, i have not brought the same question again to stackoverflow ;) Jan 22 11:12:06 anyway, i found that it wasn't about the IMAGE_INSTALL at all. it was a bug in the Makefile Jan 22 11:13:01 for some reason in the original Makefile the compiler was hard-coded to use a host compiler, which than (somewhat automagically) made bitbake decide NOT to put it on the target ;) Jan 22 11:13:40 i am not sure yet, how that worked internally, but it made sence for the build. just found the error a bit confusing ^^ Jan 22 12:05:56 When I run my multiconfig build with "bitbake multiconfig::console-image multiconfig:qemuarm64:qemu-console-image" it always starts rebuilding some parts of the qemu version, even if nothing changes in between, what could be wrong? Jan 22 12:11:04 is there a way to have layers conditionally defined based on distro/image/machine ? Jan 22 12:12:05 I remember I googled before but I forgot the results :/ was something related to filter and machine I think Jan 22 12:18:56 ohh maybe my problem is connected to that missing sstate optimizations mentioned in the docs Jan 22 12:20:32 is there some way around that or i just need to live with it? Jan 22 12:21:16 stuom1: do you have seperate tmpdirs as you ought to? Jan 22 12:21:26 yes Jan 22 12:23:00 "Consequently, if a build uses the same object twice in, for example, two different TMPDIR directories, the build either loads from an existing sstate cache for that build at the start or builds the object fresh." Jan 22 12:23:16 Who deals with the YP main website ? https://www.yoctoproject.org/ shows 3.0.1 , but https://www.yoctoproject.org/software-overview/downloads/ is still 3.0.0 Jan 22 12:23:33 this gives me the idea that maybe i shouldnt have two tmpdirs, but elsewhere it was suggested to keep separate Jan 22 12:33:20 hi, I'm coping a lot of files from git repo in do_install stage, I have problem with some files that contains characters like "[ Jan 22 12:33:51 "[" or "]" they are repesented by bitbake as "?" Jan 22 12:34:04 and rpm stage failing to do package Jan 22 12:35:21 https://github.com/dev-0x7C6/meta-retro/blob/feb5594ae9695a3a4189a67fe4c8f6e3a39e80e7/recipes-retroarch/retroarch-database/retroarch-database.bb#L43 Jan 22 12:36:05 hi there. i still don't get the mechanics behind the defconfig selection of bitbake. i keep reading, that it's sufficient to use FILESEXTRAPATHS_prepend, put a defconfig file in there and add it to the SRC_URI. but for some reason that defconfig is not used. Jan 22 12:36:12 only ${S}/cht/ contains characters "[" "]" Jan 22 12:37:02 to get more insight, i added a file to SRC_URI that fails to get some debug output, which shows me that the extended path is searched last, whereas some subfolder is autmatically searched. is that documented anywhere? Jan 22 12:37:16 my bbappend: https://pastebin.com/91k3xXwf Jan 22 12:37:16 first approach was to use cp but this also failing at rpm stage Jan 22 12:37:24 and my output: https://pastebin.com/NbQ7D3uH Jan 22 12:38:35 dev1990: do the file_names_ contain that character or the files itself? Jan 22 12:39:54 file names contain this characters Jan 22 12:40:23 dev1990: did you get some error that you could post? Jan 22 12:40:44 yes, sec Jan 22 12:40:58 typially those brackets are special characters to terminals, which might cause your problem Jan 22 12:42:59 well, repository store those files I had no choice but to copy them as is Jan 22 12:43:43 i got that, just tried to point out the direction of your problem :) Jan 22 12:43:54 still, please share a log if you can :) Jan 22 12:44:04 I'll prepare log shortly, some packages are recopiling right now, becasue I'm heavli using ${AUTOREV} in most of recipes Jan 22 12:44:24 have you ever tried copying that stuff manually? Jan 22 12:45:53 LetoThe2nd, according time stealing: "some QA issues" - that was not a question or request for help. Just a statement. Jan 22 12:46:04 https://pastebin.com/his0egkS Jan 22 12:46:44 "Nintendo - Nintendo DS/Legend of Zelda Spirit Tracks, The (U) ?Patched?.cht" but real file is "Nintendo - Nintendo DS/Legend of Zelda Spirit Tracks, The (U) [Patched].cht" Jan 22 12:46:48 for example Jan 22 12:48:27 my system encoding is UTF-8, not sure how to progress with that Jan 22 12:49:13 dev1990: going to have some lunch. i'll check your logs later :) Jan 22 12:49:26 creich: ok, thanks Jan 22 12:51:47 i wonder if meta-gpl2 should blacklist all of the recipes out of the box so they're opt-in to make you aware of what is happening Jan 22 12:55:07 RP: you're to blame for opkg-utils depending on bash 95bf5c0bba6e62283f62d95e5869921df43870ee Jan 22 12:55:19 RP: make that a recommends? Jan 22 12:57:03 in https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/package_rpm.bbclass i found lines like Jan 22 12:57:05 file = file.replace("[", "?") Jan 22 12:57:11 dir = dir.replace("[", "?") Jan 22 12:57:31 is this related to my problem with file names that contain "[" or "]" characters ? Jan 22 12:58:18 yes probably Jan 22 13:05:53 rburton: why is bash a problem for opkg-build? Jan 22 13:06:03 rburton: if you're building packages you can likely manage bash Jan 22 13:06:32 ok, I'm removing those replaces, probably there is reason for that replace in first place, just testing Jan 22 13:07:25 RP: must be a dep somewhere, without a gpl2 bash it didn't even finish parsing Jan 22 13:08:21 rburton: hmm. In principle needing bash for opkg-build shouldn't be a huge deal Jan 22 13:08:36 rburton: finding another way around the issue is fine but it was a real problem Jan 22 13:10:26 rewriting opkg-build in not-bash might be a better idea :) Jan 22 13:21:14 ok with removed replaces the situation is worse Jan 22 13:22:54 creich: I think I know the answer, rpm backend do not accept those filenames, probably this is fixable but not sure how Jan 22 13:38:16 Hi, I'm building a cross-compilation host=x86-64 target=armv8 with Yocto Sumo. I would like to add gRPC library/compiler to my SDK. Is it possible? I saw that there is a new nativesdk rule since Thud release. Jan 22 13:43:13 clementp[m]: sure is. https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#sdk-adding-individual-packages Jan 22 13:49:17 LetoThe2nd: Thanks for the answer just for my culture nativesdk is just a new rules in case the SDK machine architecture is different from the HOST ? Jan 22 13:49:17 I can add this to my script echo "TOOLCHAIN_HOST_TASK_append += \"grpc\"" >> conf/local.conf Jan 22 13:49:18 because my HOST arch is the same as the SDK arch Jan 22 13:50:11 clementp[m]: i don't know much about the specifics of that. jsut that it is supported, and that this is the way to start out. sorry. Jan 22 13:57:28 New news from stackoverflow: How to setup syslog in yocto? Jan 22 13:57:55 is there a way to have layers conditionally defined based on distro/image/machine ? some layer providers have different layers for production /demo etc so they need to be excluded on my production / distro image Jan 22 13:58:20 Ad0: not on image. that is certain. Jan 22 13:58:26 that's fine Jan 22 13:58:35 I was hoping distro would fix it Jan 22 13:58:45 if distro_features = this or that Jan 22 13:59:06 or distro name Jan 22 13:59:21 Ad0: usually thats a good approach, yes. Jan 22 14:00:31 closest thing is probably https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-BBFILES_DYNAMIC Jan 22 14:00:42 Ad0: Do you mean modify BBLAYERS based on something like distro or image? Jan 22 14:00:50 ye Jan 22 14:00:57 That's not possible Jan 22 14:01:12 hm Jan 22 14:01:16 bblayers.conf is parsed and BBLAYERS is iterated before even local.conf is parsed Jan 22 14:01:38 Let me find the slides I made that cover this Jan 22 14:02:47 ok what about this one. have a base bblayers file template where I produce a final bblayers.conf with the additional layers Jan 22 14:02:54 when I do the source init-oe-stuff Jan 22 14:03:02 Ad0: Look at pages 32 & 33 of https://wiki.yoctoproject.org/wiki/images/5/58/Yocto_Summit_Lyon_Day1_2019.pdf Jan 22 14:03:42 Ad0: That should work if your init-oe-stuff script is ran before bitbake Jan 22 14:03:58 thanks! Jan 22 14:04:56 This is why it's critical that layers play nice and don't force changes to variables or tasks without checking some machine, image or distro feature or some other config flag Jan 22 14:05:25 That's often not something you can control though if third-party layers are broken - give them a kick Jan 22 14:05:47 they have an entirely different layer for production vs demo Jan 22 14:06:11 makes it hard to have a SCM friendly structure Jan 22 14:06:19 Yep, that's very wrong! Jan 22 14:06:25 check this one https://docs.mender.io/2.0/artifacts/yocto-project/building-for-production Jan 22 14:06:38 it tells you to "bitbake-layers remove-layer ../meta-mender/meta-mender-demo Jan 22 14:06:39 " Jan 22 14:06:44 hehe Jan 22 14:07:05 thanks LetoThe2nd and paulbarker Jan 22 14:07:09 2 or 3 of the Mender devs were in my talk (where those slides are from) Jan 22 14:07:18 I am doomed to generate the bblayers.conf entirely Jan 22 14:07:48 they should have 1 layer where machine and distro_features decides it instead Jan 22 14:07:50 Raise an issue, they were interested in fixing it but I think they need it to be clearer that customers do care about this Jan 22 14:08:33 the combinations should be able to be fulfilled with for example mender_production, mender_demo as distro features, combined with machine Jan 22 14:08:46 or distro features altogether Jan 22 14:09:49 Definitely open an issue with them. I'd like to see it fixed myself Jan 22 14:09:56 will do :) Jan 22 14:10:00 thanks again Jan 22 14:10:26 I think I've seen more people doing it in that fashion Jan 22 14:27:35 New news from stackoverflow: Excluding test folders from python install path Jan 22 14:35:42 Hi! Any ideas what could be triggering glibc-locales staging failure like this on uptodate zeus: https://pastebin.com/raw/WGkgnvnB Jan 22 14:37:38 paulbarker: I know you have experience with the archiver bbclass. Do you know if it is possible to use it to extract the sources for an SDK (build using bitbake -c populate_sdk)? Jan 22 14:39:01 Saur: No idea sorry Jan 22 14:40:31 buildhistory shows that both libgcc and libgcc-initial provide that sysroot file: packages/aarch64-poky-linux/libgcc-initial/sysroot:-rw-r--r-- - - 1224 ./usr/lib/aarch64-poky-linux/9.2.0/crtendS.o Jan 22 14:40:47 packages/aarch64-poky-linux/libgcc/sysroot:-rw-r--r-- - - 1224 ./usr/lib/aarch64-poky-linux/9.2.0/crtendS.o Jan 22 14:41:43 (thanks for adding sysroot contents to buildhistory btw!) Jan 22 14:41:52 Okay, I've got a [dev-elf] QA Issue "QA Issue: -dev package contains non-symlink .so: spi-st25r-dev". I've currently learned that a simple recipe creates a bunch of packages ({PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}). Jan 22 14:42:43 Where do I find more information about what a "dev"-package normally should contain? With this bitbake output I guess it should not contain .so files Jan 22 14:42:49 ThomasD13: probably (TM) installing the .so to the proper directory should fix it. Jan 22 14:43:04 ThomasD13: so it can get picked up by the packaging mechanism Jan 22 14:43:45 paulbarker: Ok. It looks like it won't work out-of-the-box, so I guess more investigation/work is needed from my side... Jan 22 14:43:53 Ahh okay, because the .so get picked up by ${PN}-dev, before ${PN} Jan 22 14:44:23 thanks LetoThe2nd I think I've understood Jan 22 14:45:20 Saur: Yes, you'll probably need to look deeper. I'd like to test out the interaction between SDK/ESDK building and the archiver but don't have any pressing need for that myself so it's buried in my long backlog Jan 22 14:45:59 ThomasD13: For "normal" versioned DSOs, the libfoo.so symbolic link goes in ${PN}-dev, whiles the libfoo.so.1 link and libfoo.so.1.2.3 DSO goes in ${PN}. Jan 22 14:46:41 ThomasD13: However, in case the DSO isn't versioned or not setup as normal you will have to override the default configuration. Jan 22 14:49:06 Saur, sorry I have to ask: DSOs = D(?) Shared Objects ? Jan 22 14:49:14 Dynamic Jan 22 14:49:17 kk Jan 22 14:52:19 dev1990: hey dev, i am back Jan 22 14:52:32 i saw you found the place within the rpm class Jan 22 14:56:25 creich: yeah, now I'm testing build with ipk as package backend, I'll find shortly if it helps (for some reason change triggered huge recompilation) Jan 22 14:56:47 dev1990: i am not sure if it's a general problem for rpm packages or only for the bitbake class Jan 22 14:57:05 maybe you can rename the files during your do_patch phase? Jan 22 14:57:16 don't know if they have to have those names later.. Jan 22 14:57:35 ok, let me know if ipk helps Jan 22 15:01:04 Okay, issue solved :) The problem was that my DSO wasn't versioned. So the -dev package picked it up. Thanks to everyone! Jan 22 15:43:30 creich: ipk working well with that package Jan 22 15:52:39 dev1990: nice! so you'll stick with ipk i guess? Jan 22 15:52:54 about meta-clang, why does the layer.conf there do PREFERRED_PROVIDER_libgcc-initial = "libgcc-initial" ? this seems to cause my build failure even when with recipes using gcc.. Jan 22 15:57:23 * clementp[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/dUBzXMgqmhUPQvPwOVwrlkOt > Jan 22 15:59:04 creich: as workaround for now, but I'll file a bug probably. Jan 22 16:01:30 mcfrisk: seems odd as that should be the default Jan 22 16:02:30 dev1990: ok. nice that it worked out so far :) Jan 22 16:02:44 just come here again if you're going to takle the problem again Jan 22 16:03:56 RP: yea, I'll try removing it. got also glibc failing with the same error now. odd that I've not seen this ever before. A seemingly unrelated change in openssl recipes is brought these up.. Jan 22 16:37:13 I recently upgraded from sumo to zeus. I normally build core-image-minimal and the SDK. The size of my build output ballooned from 20GB to 80GB. I maintain 4 architectures and normally have two different versions going. So my disk usage has gone from 160GB to 640GB which is putting a strain on my resources. Is there anything I can do to Jan 22 16:37:13 reduce my build output size? Jan 22 16:41:29 creich: ok, thanks :) I just filled a first bug in Yocto Project bugtracker, hope it's correctly filled Jan 22 16:41:34 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13746 Jan 22 16:41:35 Bug 13746: normal, Undecided, ---, unassigned, NEW , Unable to create RPM package from repo that contains filenames with "[" and "]" characters Jan 22 16:42:17 Comparison ofsumo vs zeus build sizes - https://gist.github.com/mabnhdev/21dbe1d3db24b61f1070323ec680d7fc Jan 22 16:43:13 mabnhdev: use buildhistory to figure out which new packages are pulled and shouldn't (use BAD_RECOMMENDATIONS or bbappends with corrected PACKAGECONFIG). And you can also use INHERIT+="rm_work" in conf/local.conf but beware.. RP does not like it IIRC :) Jan 22 16:43:35 mabnhdev: check real disk usage, each recipe has a sysroot of its own in recent releases and you might be counting that over and over (its all hardlinks) Jan 22 16:43:56 surely you don't care about anything apart from deploy/ after the build anyway Jan 22 16:44:06 which was 8g -> 11g Jan 22 16:44:13 still more than i'd expect, but a lot easier to work out Jan 22 16:46:48 rburton Default for 'du' is to NOT count hardlinks, no? Jan 22 16:47:57 mabnhdev: according to your log, ./tmp/work/x86_64-poky-linux went way bigger than before. from 1.3 GB to 47 GB... maybe follow that lead to check what you've got build there Jan 22 16:48:25 mabnhdev: shouldn't be. of course if you copied that somewhere before counting, links could have been lost Jan 22 16:49:24 usually there are host tools and stuff. maybe you used external toolchains before or something like that? Jan 22 16:55:16 @creich: Drilling down into x86_64-poky-linux it looks like the output of each recipe is significantly larger. For example: smartmontools went from 3.0MB => 79MB. Jan 22 16:59:30 sorry, on my way out atm... will be back here later. good luck hunting in the mean time :) Jan 22 16:59:51 @mabnhdev: I moved from sumo to zeus on Arm and on Ubuntu 16 and 18 had to increase the default 1Gig swap when building an sdk to avoid the OOM killer. Jan 22 17:01:31 mabnhdev: if all of them are significantly bigger, try to isolate which recipe populates the sysroot of others with that many files **** BEGIN LOGGING AT Wed Jan 22 17:15:33 2020 Jan 22 17:16:25 @qschulz: Thanks for the suggestion. In the meantime, INHERIT+="rm_work" gets me out of immediate trouble. Jan 22 17:24:51 fwiw, I use rm_work for years and build a lot. no problems with it really. oom happens for other reasons when c++ and template people get out of hand but that's a different problem.. Jan 22 17:25:57 also sumo to zeus brough around 15% increase in target rootfs sizes in a couple of projects. small increases everywhere and then mozjs as dependency of polkit was the biggest size regression Jan 22 17:50:11 @mcfrisk: Well the strange thing is that may YP/OE versions until zeus were happy with the default swap. I have 8 Gigs of RAM in the machines and only when I build core-image-sato-sdk -c populate_sdk OOM kicks in. Maybe I should file a bug for that ;) Jan 22 17:51:30 @mcfrisk: The populate_sdk step seems to be the evil one. Jan 22 17:57:43 RobertBerger: there is evil within the YP? *gasp* Jan 22 17:59:53 @LetoThe2nd: Only somewhere in the populate_sdk task ;) Jan 22 18:00:56 * LetoThe2nd makes note to himself: hide it better for the next release. Jan 22 18:00:58 @LetoThe2nd: Something in there wants to eat a lot of RAM ;) Jan 22 18:01:22 OTOH, 8GiB is like, meh, anyways :P Jan 22 18:06:37 @LetoThe2nd: Until zeus came down from mount olympos to visit us it was good enough ;) Jan 22 18:09:59 @LetoThe2nd: ... and I used to have vms which did not use more than 2 Gigs ;) - just monitor RAM usage it's not that bad most of the time with "standard" stuff. As @mcfrisk said above RAM usage is getting really bad with c++ templates, but then you are asking for it. I hope the populate_sdk task is not secretly written with c++ templates ;) Jan 22 18:25:26 ram prices going down Jan 22 18:26:03 in 2018/ early 2019 ram was super expensive Jan 22 18:29:56 RP: Most of these reproducible issues are because of host tool differences :( Jan 22 18:51:08 JPEW: hmm, not good :( Which tool(s)? Jan 22 18:52:07 RP: makeinfo, and the perl reproduciblity is because of host GCC version Jan 22 18:52:32 Might be able to patch around the perl one... basically it generates different output based on the host GCC version Jan 22 18:53:23 Also, a lot of ptest packages have SHELL = /bin/sh vs. SHELL = /bin/bash in the make file (I think that about half the errors) Jan 22 18:53:36 JPEW: the libx11 multilib bug i just fixed was due to the host compiler too Jan 22 18:53:53 JPEW: I guess we could at least brute force that problem Jan 22 18:54:16 mandate a buildtools tarball? :/ Jan 22 18:54:20 RP: Ya, I think I've had to do that in a few other recipes anyway Jan 22 18:56:13 we could just export SHELL=/bin/bash... Jan 22 18:56:21 can we actually build without a host bash? Jan 22 18:56:58 I think in the other cases I just used sed to remove the SHELL line from the makefile Jan 22 18:57:17 These are the Makefiles used for ptest, not the actual build Jan 22 18:57:27 JPEW: as long as it isn't used that should be fine Jan 22 18:57:40 RP: It hasn't been, but I'll make sure Jan 22 18:58:10 It... might take a while to work through these, but as I stated, I don't think any of these are from the INHIBIT_STRIP Jan 22 18:58:36 JPEW: what happened to suddenly expose a load then? :/ Jan 22 18:58:52 JPEW: M2 build is failing with a load of these failures too :/ Jan 22 18:59:05 not as many as that other build mind Jan 22 18:59:39 I'm not sure Jan 22 19:01:01 Hello again. I have been making progress with my yocto.... begining (?). At least I hope the questions I bring to you are not as... trivial as they might have been during last und this week. Jan 22 19:02:01 Now, does anybody know if there is a way to create a soft link in /opt, in the host machine, when triggering the script that boots up the sdk environment? Jan 22 19:02:41 nemgti-og, Traditional SDK or eSDK? Jan 22 19:02:53 traditional Jan 22 19:03:20 There are post-install scripts you can add to do whatever you want when the SDK is installed Jan 22 19:03:28 * JPEW Looks for an example... Jan 22 19:03:40 is there a way to depend on a recipe only for its side effect of creating packages? Jan 22 19:04:40 nemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-too Jan 22 19:04:49 nemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-toolchain_0.1.bb Jan 22 19:05:22 alright. Thanks a lot JPEW ! Jan 22 19:32:03 Hey, am trying to get the example recipe created with `bitbake-layers create-layer` to run but it seems to be ignored Jan 22 19:32:07 https://pastebin.com/GshWUzpb Jan 22 19:33:11 I've added the extra line to force it to run each time, but the `bb.plain("* Example recipe created by bitbake-layers *");` never ends up printed Jan 22 19:33:27 (This is on zeus) Jan 22 19:34:53 MeanEngi: not printed, or not logged? Jan 22 19:36:13 LetoThe2nd: It doesn't show in stdout as the result of executing bitbake. Guess that would fall under printed Jan 22 19:37:10 I've tried the "hello world bitbake" example in which same recipe results in output visible Jan 22 19:37:59 "hello world bitbake" - the one where you try to get the barebones structure for bitbake to work. No poky involved Jan 22 19:38:30 MeanEngi: yup. have you checked whats in tmp/work/example/0.1/SOMETHINGIDONTREMEMBERRIGHTNOW/temp/log.do_build ? Jan 22 19:38:39 and the other logs there too, ofc? Jan 22 19:40:42 Hm... Jan 22 19:40:50 There doesn't seem to be any Jan 22 19:41:23 then theres something really wrong. but the directory structure i described is roughly there? Jan 22 19:41:44 Yup https://pastebin.com/7REft8RG Jan 22 19:42:59 can you give it a bitbake -c listtasks example? Jan 22 19:45:26 LetoThe2nd: https://pastebin.com/Rmt8eeB8 Jan 22 19:46:35 Nothing much seems to be happening in the recipe: https://pastebin.com/dEPQYeXL Jan 22 19:48:05 what happens upon bitbake -c build example ? Jan 22 19:48:58 LetoThe2nd: https://pastebin.com/57GE8Li7 Jan 22 19:50:07 and after that, there is still no log for do_build? Jan 22 19:50:16 Nope Jan 22 19:50:27 hum. no idea then, sorry. Jan 22 19:51:14 LetoThe2nd: Fair, thanks :) Jan 22 19:51:52 i might be missing something obvious too, but still i think it should run the task. care to file a bug? against bitbake-layer, preferably. Jan 22 19:54:17 I'll dig a bit and post if something comes up Jan 22 21:46:50 I have a meta-layer I'm trying to update (meta-sdl) but it depends on openssl10. Adding openssl10 to my DEPENDS introduces build errors as I think some dependencies require openssl and they both try and install the same files. Jan 22 21:47:13 Do I have any recourse other than updating the src to work with openssl1.1? Jan 22 23:01:26 which release are you on Jan 22 23:02:35 in meta-sdl if a package depends on upon both openssl1.1.x and openssl10 then it will need solving at package level perhaps upgrade that package to use newer ssl Jan 22 23:06:33 it's the conflict in RSS (before packages are even created) Jan 22 23:07:01 whole dependency tree needs to use the same openssl version Jan 22 23:07:47 I was using openssl10 for everything (from recipe called openssl to prevent incompatible 1.1 version ever leaking into our builds) Jan 22 23:09:21 until I could get rid of it at least from OSE version in https://github.com/webosose/meta-webosose/commit/d0a436fa08ab7e732845afb07d95ed7e6616a2ae Jan 22 23:18:55 hello... Hi, I have a package (psplash) I m interested in building as part of poky core-image-minimal. I have added it to my custom distro config in meta-mydistro/conf/distro/mydistro.conf as IMAGE_FEATURES_append = " splash" Jan 22 23:19:12 after doing that I see psplash when I do "bitbake -g core-image-minimal && cat pn-buildlist |grep 'psplash' " Jan 22 23:19:19 however the image does not seem to have this package Jan 22 23:19:26 also the package is not seen in the manifest file of the image inside tmp/deploy/images//imagename.manifest Jan 22 23:19:36 what could be wrong..how can I make sure a package is built. And how can I debug what is wrong and why is the pacakge not building Jan 22 23:55:46 kiwi_29: there are several possible points to check Jan 22 23:57:14 e.g. you could check your build/tmp/work/ if there is any folder with the name of the package -->$ find /build/tmp/work/ -iname "*NAME-OF-PACKAGE*" Jan 22 23:57:43 check if it's a subfolder of the architecture you're building for. Jan 22 23:58:33 kiwi_29: also you could post a build log of -->$ bitbake -f psplash Jan 23 01:12:36 creich thanks . I added IMAGE_INSTALL_append = " psplash" and it is building psplash now Jan 23 01:13:05 now I have to get a psplash recipe that supports systemd as the one that I have supports sysvinit Jan 23 01:13:15 or will have to write one myself **** ENDING LOGGING AT Thu Jan 23 02:59:57 2020