*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:02 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 00:11 | |
mischief | also, im confused by how kernel-module-split and RPROVIDES works | 00:18 |
---|---|---|
mischief | if recipe foo-modules.bb creates kernel-module-foo and i add kernel-module-foo to RDEPENDS, how does bitbake know that foo-modules.bb makes kernel-module-foo if foo-modules.bb wasn't also added to RDEPENDS? | 00:19 |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:22 | |
creich | mischief: i am not sure, but as far as i understood, 'require' and 'MACHINE_FEATURE' are not achiving the same thing! | 00:23 |
creich | require is just an explicit way of including settings fomr another file into your recipe. with the difference to a simple 'include' that it would fail in case the file to be included is not found! | 00:24 |
mischief | creich: i have a simple case - i want to MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-foo" and KERNEL_MODULE_AUTOLOAD += "foo" | 00:25 |
creich | so e.g. if you write some recipe and split it in some kind of generic part like your_recipe.inc and some version specific part like your_recipe_0.1.0.bb you can make the .inc a requirement within the bb file | 00:25 |
mischief | should i put that in a .inc and require it, or should i also wrap it in ${@bb.utils.contains('MACHINE_FEATURES', 'foomod',...)}" and set MACHINE_FEATURES += "foomod"? | 00:26 |
creich | i still feel that you kind of mix up two concepts here | 00:27 |
creich | wether or not you put it in an .inc is part of your development process. | 00:27 |
creich | since i am not sure how to handle kernel_modules, i can not really help with the other thing, sorry | 00:28 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 00:37 | |
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has quit IRC | 00:55 | |
*** inf <inf!~informati@unaffiliated/informatic> has quit IRC | 00:59 | |
*** inf <inf!~informati@unaffiliated/informatic> has joined #yocto | 01:00 | |
creich | ok, now i figured out that my defconfig file would be used when i create a subfolder 'poky' since it seems like bitbake looks there first. only putting it into the folder i added with FILESEXTRAPATHS_prepend did not help! | 01:00 |
creich | so here are two questions. 1) how can it be, that my added path is not searched first, since i put _prepend to it? | 01:01 |
creich | 2) is there any way to get the folders listed that bitbake will search? i just used another bug-log to figure the hierarchy and then created the new folder | 01:02 |
creich | thx in advance :) | 01:02 |
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 02:07 | |
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 02:08 | |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9d1b:2c63:9ae4:da9e> has joined #yocto | 02:09 | |
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9d1b:2c63:9ae4:da9e> has left #yocto | 02:11 | |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 02:16 | |
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 02:22 | |
*** davisr <davisr!~davisr@cpe-184-58-235-7.wi.res.rr.com> has quit IRC | 02:28 | |
khem | perhaps show the code which is failing can give better idea | 02:59 |
*** mario-goulart <mario-goulart!~user@static.107.70.9.5.clients.your-server.de> has quit IRC | 02:59 | |
khem | poky is DISTRO so any value that is DISTRO will be appended to path and so will be MACHINE, if you add poky dir then you are effectively saying this defconfig is only applicable when building for poky distro | 03:00 |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 03:43 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has joined #yocto | 04:51 | |
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 05:09 | |
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto | 05:10 | |
armpit | 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 | 05:30 |
*** sgw1 <sgw1!~sgw@134.134.139.76> has joined #yocto | 05:39 | |
*** milloni_ <milloni_!~milloni@preemptable.org> has joined #yocto | 05:41 | |
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has quit IRC | 05:41 | |
*** sgw <sgw!~sgw@134.134.139.76> has quit IRC | 05:41 | |
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC | 05:41 | |
*** milloni <milloni!~milloni@preemptable.org> has quit IRC | 05:41 | |
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has joined #yocto | 05:43 | |
*** mario-goulart <mario-goulart!~user@static.107.70.9.5.clients.your-server.de> has joined #yocto | 06:17 | |
*** mmadej <mmadej!~mariusz@azz22.internetdsl.tpnet.pl> has joined #yocto | 06:20 | |
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 06:22 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:24 | |
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 06:34 | |
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:53 | |
*** agust <agust!~agust@p508B64CC.dip0.t-ipconnect.de> has joined #yocto | 07:04 | |
ThomasD13 | 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". | 07:10 |
LetoThe2nd | ThomasD13: i take it that you have already watched https://youtu.be/IehnEC3GOGU ? | 07:11 |
ThomasD13 | 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 | 07:12 |
ThomasD13 | LetoThe2nd, no I did not yet. I watched the first two, and the 7 or 8. video from you | 07:13 |
LetoThe2nd | ThomasD13: its covering the very exact situation that you have. cmake project, which builds a lib and an application, both to be packaged seperately. | 07:13 |
ThomasD13 | However, Yocto says it cannot find "rfal_lib" which is "B" in my example | 07:13 |
LetoThe2nd | ThomasD13: no, its not yocto saying that. this is cmake barfing out on you getting the linkage wrong | 07:14 |
LetoThe2nd | ThomasD13: check against https://github.com/LetoThe2nd/libanswer | 07:14 |
ThomasD13 | LetoThe2nd, okay - That was my question now: So its basically a problem to provide a package which has only "internal" dependencies? | 07:14 |
LetoThe2nd | please see video :) | 07:15 |
ThomasD13 | alright ;) | 07:15 |
erbo | 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? | 07:18 |
*** mmadej <mmadej!~mariusz@azz22.internetdsl.tpnet.pl> has quit IRC | 07:20 | |
*** frsc <frsc!~frsc@i59F729EB.versanet.de> has joined #yocto | 07:32 | |
ThomasD13 | 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 | 07:44 |
ThomasD13 | 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 | 07:46 |
ThomasD13 | And then watch the video ;) | 07:46 |
LetoThe2nd | ThomasD13: then how could the package in the video build? during the linking stage, cmake is totally unaware of any form of installation whatsoever. | 07:47 |
LetoThe2nd | so my first and foremost guess is that your library dependencies inside CMakeLists.txt are off. | 07:48 |
ThomasD13 | 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 | 07:54 |
erbo | I agree with LetoThe2nd, this is most likely a CMakeLists issue | 07:54 |
ThomasD13 | Don't get me wrong, I hope also this is a CMakeList problem. I guess thats much easier to fix as something with yocto | 07:55 |
erbo | ThomasD13: Since you didn't use parallel make, maybe you're lib is always built before the app. | 07:55 |
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has joined #yocto | 07:55 | |
erbo | s/you're/your/ | 07:55 |
ThomasD13 | erbo, I think the lib must be built before the app, since it's linked to it | 07:55 |
erbo | ThomasD13: of course, but did you state that in the CMakeLists file? | 07:56 |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:57 | |
erbo | You can try building the recipe without parallel make by disabling it in the recipe: PARALLEL_MAKE = "" | 07:58 |
erbo | 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 | 07:58 |
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 08:00 | |
ThomasD13 | 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 ;) | 08:00 |
erbo | ThomasD13: do you have a top-level CMakeLists which uses the other two? | 08:00 |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has joined #yocto | 08:00 | |
ThomasD13 | erbo, this is it: https://pastebin.com/v9WT8abB | 08:01 |
*** hpsy <hpsy!~hpsy@62.96.159.122> has joined #yocto | 08:03 | |
erbo | ThomasD13: I'm no CMake expert, but I think something like "add_dependencies (exampleNFC rfal_lib)" in the apps CMakeLists might solve it | 08:04 |
ThomasD13 | erbo, I'll check that, thank you very much. | 08:05 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:07 | |
*** hpsy <hpsy!~hpsy@62.96.159.122> has quit IRC | 08:11 | |
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 08:12 | |
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 08:41 | |
ThomasD13 | 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? | 08:45 |
LetoThe2nd | 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?) | 08:50 |
ThomasD13 | 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 | 08:52 |
LetoThe2nd | 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? | 08:53 |
LetoThe2nd | and yes, QA things are to be taken *SERIOUSLY* unless you know exactly what caused them, and can properly judge that its false positives. | 08:54 |
ThomasD13 | 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 | 08:57 |
ThomasD13 | why I want to google first | 08:57 |
qschulz | https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-qa-checks | 08:58 |
LetoThe2nd | 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. | 08:59 |
LetoThe2nd | 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. | 09:00 |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:00 | |
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto | 09:14 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has joined #yocto | 09:17 | |
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 09:19 | |
yocti | New news from stackoverflow: Yocto packagegroup install <https://stackoverflow.com/questions/59855994/yocto-packagegroup-install> | 09:26 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:28 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:32 | |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has quit IRC | 09:33 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:34 | |
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC | 09:40 | |
LetoThe2nd | session #10 uploaded 12hrs ago, already >60 views on YT | 09:40 |
* LetoThe2nd enters full rockstar mode! | 09:40 | |
nrossi | LetoThe2nd: time for a promotion to LetoTheGreat? :) | 09:43 |
LetoThe2nd | nrossi: i am already god emperor of the known universe. hard to be promoted any further. | 09:44 |
qschulz | LetoThe2nd: last yocti message: isn't it the same thing as yesterday? i.e. CORE_IMAGE_EXTRA_INSTALL and not IMAGE_INSTALL? | 09:44 |
nrossi | LetoThe2nd: time to expand to the multi-verse :) | 09:44 |
LetoThe2nd | nrossi: hehe | 09:44 |
LetoThe2nd | qschulz: no iea. | 09:45 |
qschulz | LetoThe2nd: I sent a comment, we'll see :) | 09:48 |
*** rburton <rburton!Adium@nat/intel/x-odlakjtmrsarrfyl> has joined #yocto | 09:51 | |
*** rburton <rburton!Adium@nat/intel/x-odlakjtmrsarrfyl> has quit IRC | 09:54 | |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has joined #yocto | 09:59 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 10:00 | |
erbo | qschulz: I think it looks correct, but I also added a comment with an idea | 10:16 |
qschulz | erbo: mmm good point as well, I always forget about this renaming of packages if they only contain a lib | 10:50 |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC | 10:53 | |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto | 10:56 | |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has joined #yocto | 11:10 | |
creich | 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 ;) | 11:11 |
*** PaowZ <PaowZ!~Vince@193.252.149.222> has quit IRC | 11:12 | |
creich | anyway, i found that it wasn't about the IMAGE_INSTALL at all. it was a bug in the Makefile | 11:12 |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has quit IRC | 11:12 | |
creich | 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 ;) | 11:13 |
creich | i am not sure yet, how that worked internally, but it made sence for the build. just found the error a bit confusing ^^ | 11:13 |
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto | 11:14 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has quit IRC | 11:17 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has quit IRC | 11:34 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has joined #yocto | 11:36 | |
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto | 11:38 | |
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has joined #yocto | 11:48 | |
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 11:49 | |
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/irccloud.com/x-jmqrtodvtvlzughw> has joined #yocto | 11:53 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has joined #yocto | 11:57 | |
*** berton <berton!~berton@177.194.196.4> has joined #yocto | 11:59 | |
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 12:00 | |
stuom1 | 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? | 12:05 |
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 12:06 | |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has joined #yocto | 12:09 | |
Ad0 | is there a way to have layers conditionally defined based on distro/image/machine ? | 12:11 |
Ad0 | I remember I googled before but I forgot the results :/ was something related to filter and machine I think | 12:12 |
*** berton <berton!~berton@177.194.196.4> has quit IRC | 12:13 | |
*** berton <berton!~berton@177.194.196.4> has joined #yocto | 12:14 | |
stuom1 | ohh maybe my problem is connected to that missing sstate optimizations mentioned in the docs | 12:18 |
stuom1 | is there some way around that or i just need to live with it? | 12:20 |
LetoThe2nd | stuom1: do you have seperate tmpdirs as you ought to? | 12:21 |
stuom1 | yes | 12:21 |
stuom1 | "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." | 12:23 |
dl9pf | 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 | 12:23 |
stuom1 | this gives me the idea that maybe i shouldnt have two tmpdirs, but elsewhere it was suggested to keep separate | 12:23 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.130> has joined #yocto | 12:25 | |
dev1990 | 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 "[ | 12:33 |
dev1990 | "[" or "]" they are repesented by bitbake as "?" | 12:33 |
dev1990 | and rpm stage failing to do package | 12:34 |
dev1990 | https://github.com/dev-0x7C6/meta-retro/blob/feb5594ae9695a3a4189a67fe4c8f6e3a39e80e7/recipes-retroarch/retroarch-database/retroarch-database.bb#L43 | 12:35 |
creich | 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. | 12:36 |
dev1990 | only ${S}/cht/ contains characters "[" "]" | 12:36 |
creich | 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? | 12:37 |
creich | my bbappend: https://pastebin.com/91k3xXwf | 12:37 |
dev1990 | first approach was to use cp but this also failing at rpm stage | 12:37 |
creich | and my output: https://pastebin.com/NbQ7D3uH | 12:37 |
creich | dev1990: do the file_names_ contain that character or the files itself? | 12:38 |
dev1990 | file names contain this characters | 12:39 |
creich | dev1990: did you get some error that you could post? | 12:40 |
dev1990 | yes, sec | 12:40 |
creich | typially those brackets are special characters to terminals, which might cause your problem | 12:40 |
dev1990 | well, repository store those files I had no choice but to copy them as is | 12:42 |
creich | i got that, just tried to point out the direction of your problem :) | 12:43 |
creich | still, please share a log if you can :) | 12:43 |
dev1990 | I'll prepare log shortly, some packages are recopiling right now, becasue I'm heavli using ${AUTOREV} in most of recipes | 12:44 |
creich | have you ever tried copying that stuff manually? | 12:44 |
ThomasD13 | LetoThe2nd, according time stealing: "some QA issues" - that was not a question or request for help. Just a statement. | 12:45 |
dev1990 | https://pastebin.com/his0egkS | 12:46 |
dev1990 | "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" | 12:46 |
dev1990 | for example | 12:46 |
dev1990 | my system encoding is UTF-8, not sure how to progress with that | 12:48 |
creich | dev1990: going to have some lunch. i'll check your logs later :) | 12:49 |
dev1990 | creich: ok, thanks | 12:49 |
*** hpsy <hpsy!~hpsy@62.96.159.122> has joined #yocto | 12:50 | |
*** rburton <rburton!~rburton@192.198.151.43> has joined #yocto | 12:51 | |
rburton | 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 | 12:51 |
rburton | RP: you're to blame for opkg-utils depending on bash 95bf5c0bba6e62283f62d95e5869921df43870ee | 12:55 |
rburton | RP: make that a recommends? | 12:55 |
dev1990 | in https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/package_rpm.bbclass i found lines like | 12:57 |
dev1990 | file = file.replace("[", "?") | 12:57 |
dev1990 | dir = dir.replace("[", "?") | 12:57 |
dev1990 | is this related to my problem with file names that contain "[" or "]" characters ? | 12:57 |
rburton | yes probably | 12:58 |
RP | rburton: why is bash a problem for opkg-build? | 13:05 |
RP | rburton: if you're building packages you can likely manage bash | 13:06 |
dev1990 | ok, I'm removing those replaces, probably there is reason for that replace in first place, just testing | 13:06 |
rburton | RP: must be a dep somewhere, without a gpl2 bash it didn't even finish parsing | 13:07 |
RP | rburton: hmm. In principle needing bash for opkg-build shouldn't be a huge deal | 13:08 |
RP | rburton: finding another way around the issue is fine but it was a real problem | 13:08 |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 13:09 | |
rburton | rewriting opkg-build in not-bash might be a better idea :) | 13:10 |
*** berton_ <berton_!~berton@177.194.196.4> has joined #yocto | 13:10 | |
*** berton <berton!~berton@177.194.196.4> has quit IRC | 13:13 | |
dev1990 | ok with removed replaces the situation is worse | 13:21 |
dev1990 | creich: I think I know the answer, rpm backend do not accept those filenames, probably this is fixable but not sure how | 13:22 |
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-ncynqoekvtdoiddg> has joined #yocto | 13:32 | |
*** goliath <goliath!~goliath@nat008-WLTE1.uibk.ac.at> has quit IRC | 13:34 | |
clementp[m] | 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. | 13:38 |
LetoThe2nd | clementp[m]: sure is. https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#sdk-adding-individual-packages | 13:43 |
clementp[m] | 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 ? | 13:48 |
clementp[m] | I can add this to my script echo "TOOLCHAIN_HOST_TASK_append += \"grpc\"" >> conf/local.conf | 13:48 |
clementp[m] | because my HOST arch is the same as the SDK arch | 13:49 |
LetoThe2nd | 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. | 13:50 |
*** develonepi3 <develonepi3!~devel@2600:1700:69f0:42c0::a> has joined #yocto | 13:55 | |
yocti | New news from stackoverflow: How to setup syslog in yocto? <https://stackoverflow.com/questions/41868231/how-to-setup-syslog-in-yocto> | 13:57 |
Ad0 | 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 | 13:57 |
LetoThe2nd | Ad0: not on image. that is certain. | 13:58 |
Ad0 | that's fine | 13:58 |
Ad0 | I was hoping distro would fix it | 13:58 |
Ad0 | if distro_features = this or that | 13:58 |
Ad0 | or distro name | 13:59 |
LetoThe2nd | Ad0: usually thats a good approach, yes. | 13:59 |
*** PaowZ <PaowZ!~Vince@193.252.149.222> has joined #yocto | 14:00 | |
LetoThe2nd | closest thing is probably https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-BBFILES_DYNAMIC | 14:00 |
paulbarker | Ad0: Do you mean modify BBLAYERS based on something like distro or image? | 14:00 |
Ad0 | ye | 14:00 |
paulbarker | That's not possible | 14:00 |
Ad0 | hm | 14:01 |
paulbarker | bblayers.conf is parsed and BBLAYERS is iterated before even local.conf is parsed | 14:01 |
paulbarker | Let me find the slides I made that cover this | 14:01 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 14:01 | |
Ad0 | ok what about this one. have a base bblayers file template where I produce a final bblayers.conf with the additional layers | 14:02 |
Ad0 | when I do the source init-oe-stuff | 14:02 |
paulbarker | Ad0: Look at pages 32 & 33 of https://wiki.yoctoproject.org/wiki/images/5/58/Yocto_Summit_Lyon_Day1_2019.pdf | 14:03 |
paulbarker | Ad0: That should work if your init-oe-stuff script is ran before bitbake | 14:03 |
Ad0 | thanks! | 14:03 |
paulbarker | 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 | 14:04 |
paulbarker | That's often not something you can control though if third-party layers are broken - give them a kick | 14:05 |
Ad0 | they have an entirely different layer for production vs demo | 14:05 |
Ad0 | makes it hard to have a SCM friendly structure | 14:06 |
paulbarker | Yep, that's very wrong! | 14:06 |
Ad0 | check this one https://docs.mender.io/2.0/artifacts/yocto-project/building-for-production | 14:06 |
Ad0 | it tells you to "bitbake-layers remove-layer ../meta-mender/meta-mender-demo | 14:06 |
Ad0 | " | 14:06 |
Ad0 | hehe | 14:06 |
Ad0 | thanks LetoThe2nd and paulbarker | 14:07 |
paulbarker | 2 or 3 of the Mender devs were in my talk (where those slides are from) | 14:07 |
Ad0 | I am doomed to generate the bblayers.conf entirely | 14:07 |
Ad0 | they should have 1 layer where machine and distro_features decides it instead | 14:07 |
paulbarker | Raise an issue, they were interested in fixing it but I think they need it to be clearer that customers do care about this | 14:07 |
Ad0 | the combinations should be able to be fulfilled with for example mender_production, mender_demo as distro features, combined with machine | 14:08 |
Ad0 | or distro features altogether | 14:08 |
paulbarker | Definitely open an issue with them. I'd like to see it fixed myself | 14:09 |
Ad0 | will do :) | 14:09 |
Ad0 | thanks again | 14:10 |
Ad0 | I think I've seen more people doing it in that fashion | 14:10 |
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC | 14:14 | |
*** RobertBerger <RobertBerger!~rber@athedsl-4432938.home.otenet.gr> has quit IRC | 14:26 | |
yocti | New news from stackoverflow: Excluding test folders from python install path <https://stackoverflow.com/questions/59861570/excluding-test-folders-from-python-install-path> | 14:27 |
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:28 | |
*** JPEW56 <JPEW56!cc4da369@204.77.163.105> has quit IRC | 14:30 | |
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 14:30 | |
mcfrisk | Hi! Any ideas what could be triggering glibc-locales staging failure like this on uptodate zeus: https://pastebin.com/raw/WGkgnvnB | 14:35 |
Saur | 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)? | 14:37 |
paulbarker | Saur: No idea sorry | 14:39 |
mcfrisk | 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 | 14:40 |
mcfrisk | packages/aarch64-poky-linux/libgcc/sysroot:-rw-r--r-- - - 1224 ./usr/lib/aarch64-poky-linux/9.2.0/crtendS.o | 14:40 |
mcfrisk | (thanks for adding sysroot contents to buildhistory btw!) | 14:41 |
ThomasD13 | 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}). | 14:41 |
ThomasD13 | 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 | 14:42 |
LetoThe2nd | ThomasD13: probably (TM) installing the .so to the proper directory should fix it. | 14:42 |
LetoThe2nd | ThomasD13: so it can get picked up by the packaging mechanism | 14:43 |
Saur | paulbarker: Ok. It looks like it won't work out-of-the-box, so I guess more investigation/work is needed from my side... | 14:43 |
ThomasD13 | Ahh okay, because the .so get picked up by ${PN}-dev, before ${PN} | 14:43 |
ThomasD13 | thanks LetoThe2nd I think I've understood | 14:44 |
paulbarker | 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 | 14:45 |
Saur | 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}. | 14:45 |
Saur | ThomasD13: However, in case the DSO isn't versioned or not setup as normal you will have to override the default configuration. | 14:46 |
*** sgw1 is now known as sgw | 14:48 | |
ThomasD13 | Saur, sorry I have to ask: DSOs = D(?) Shared Objects ? | 14:49 |
Saur | Dynamic | 14:49 |
ThomasD13 | kk | 14:49 |
creich | dev1990: hey dev, i am back | 14:52 |
creich | i saw you found the place within the rpm class | 14:52 |
*** RobertBerger <RobertBerger!~rber@2a02:587:3b17:4040:4c07:692c:3325:fe6a> has joined #yocto | 14:55 | |
dev1990 | 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) | 14:56 |
creich | dev1990: i am not sure if it's a general problem for rpm packages or only for the bitbake class | 14:56 |
creich | maybe you can rename the files during your do_patch phase? | 14:57 |
creich | don't know if they have to have those names later.. | 14:57 |
creich | ok, let me know if ipk helps | 14:57 |
ThomasD13 | Okay, issue solved :) The problem was that my DSO wasn't versioned. So the -dev package picked it up. Thanks to everyone! | 15:01 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:02 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 15:02 | |
*** grma <grma!~gruberm@80.93.38.128> has quit IRC | 15:13 | |
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:18 | |
*** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 15:23 | |
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 15:24 | |
*** RobertBerger <RobertBerger!~rber@2a02:587:3b17:4040:4c07:692c:3325:fe6a> has quit IRC | 15:29 | |
*** comptroller <comptroller!~comptroll@47-213-227-146.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 15:34 | |
dev1990 | creich: ipk working well with that package | 15:43 |
*** RobertBerger <RobertBerger!~rber@athedsl-4432938.home.otenet.gr> has joined #yocto | 15:47 | |
creich | dev1990: nice! so you'll stick with ipk i guess? | 15:52 |
mcfrisk | 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.. | 15:52 |
* clementp[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/dUBzXMgqmhUPQvPwOVwrlkOt > | 15:57 | |
dev1990 | creich: as workaround for now, but I'll file a bug probably. | 15:59 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:00 | |
RP | mcfrisk: seems odd as that should be the default | 16:01 |
creich | dev1990: ok. nice that it worked out so far :) | 16:02 |
creich | just come here again if you're going to takle the problem again | 16:02 |
mcfrisk | 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.. | 16:03 |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:09 | |
*** cpo <cpo!~cpo@helix.mybll.net> has quit IRC | 16:18 | |
*** cpo <cpo!~cpo@helix.mybll.net> has joined #yocto | 16:19 | |
*** piksu <piksu!575c74e5@87-92-116-229.bb.dnainternet.fi> has joined #yocto | 16:32 | |
*** mabnhdev <mabnhdev!0c260e08@12.38.14.8> has joined #yocto | 16:33 | |
mabnhdev | 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 | 16:37 |
mabnhdev | reduce my build output size? | 16:37 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 16:39 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 16:40 | |
dev1990 | creich: ok, thanks :) I just filled a first bug in Yocto Project bugtracker, hope it's correctly filled | 16:41 |
dev1990 | https://bugzilla.yoctoproject.org/show_bug.cgi?id=13746 | 16:41 |
yocti | Bug 13746: normal, Undecided, ---, unassigned, NEW , Unable to create RPM package from repo that contains filenames with "[" and "]" characters | 16:41 |
mabnhdev | Comparison ofsumo vs zeus build sizes - https://gist.github.com/mabnhdev/21dbe1d3db24b61f1070323ec680d7fc | 16:42 |
qschulz | 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 :) | 16:43 |
rburton | 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) | 16:43 |
rburton | surely you don't care about anything apart from deploy/ after the build anyway | 16:43 |
rburton | which was 8g -> 11g | 16:44 |
rburton | still more than i'd expect, but a lot easier to work out | 16:44 |
mabnhdev | rburton Default for 'du' is to NOT count hardlinks, no? | 16:46 |
creich | 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 | 16:47 |
rburton | mabnhdev: shouldn't be. of course if you copied that somewhere before counting, links could have been lost | 16:48 |
creich | usually there are host tools and stuff. maybe you used external toolchains before or something like that? | 16:49 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 16:49 | |
mabnhdev | @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. | 16:55 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 16:57 | |
*** yacar_ <yacar_!~yacar_@static-css-csd-172251.business.bouyguestelecom.com> has quit IRC | 16:58 | |
*** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has left #yocto | 16:59 | |
creich | sorry, on my way out atm... will be back here later. good luck hunting in the mean time :) | 16:59 |
RobertBerger | @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. | 16:59 |
qschulz | mabnhdev: if all of them are significantly bigger, try to isolate which recipe populates the sysroot of others with that many files | 17:01 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 17:02 | |
*** pidge <pidge!~pidge@80.233.42.99> has joined #yocto | 17:03 | |
*** hpsy <hpsy!~hpsy@62.96.159.122> has quit IRC | 17:08 | |
*** nslu2-log_ <nslu2-log_!~nslu2-log@milla.nas-admin.org> has joined #yocto | 17:15 | |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 17:15 | |
mabnhdev | @qschulz: Thanks for the suggestion. In the meantime, INHERIT+="rm_work" gets me out of immediate trouble. | 17:16 |
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 17:17 | |
*** nslu2-log_ is now known as nslu2-log | 17:17 | |
mcfrisk | 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.. | 17:24 |
mcfrisk | 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 | 17:25 |
*** frsc <frsc!~frsc@i59F729EB.versanet.de> has quit IRC | 17:26 | |
*** hpsy <hpsy!~hpsy@93.240.132.122> has joined #yocto | 17:27 | |
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/irccloud.com/x-jmqrtodvtvlzughw> has quit IRC | 17:31 | |
*** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has quit IRC | 17:31 | |
*** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has joined #yocto | 17:36 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.130> has quit IRC | 17:38 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 17:40 | |
RobertBerger | @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 ;) | 17:50 |
RobertBerger | @mcfrisk: The populate_sdk step seems to be the evil one. | 17:51 |
LetoThe2nd | RobertBerger: there is evil within the YP? *gasp* | 17:57 |
RobertBerger | @LetoThe2nd: Only somewhere in the populate_sdk task ;) | 17:59 |
* LetoThe2nd makes note to himself: hide it better for the next release. | 18:00 | |
RobertBerger | @LetoThe2nd: Something in there wants to eat a lot of RAM ;) | 18:00 |
LetoThe2nd | OTOH, 8GiB is like, meh, anyways :P | 18:01 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 18:04 | |
RobertBerger | @LetoThe2nd: Until zeus came down from mount olympos to visit us it was good enough ;) | 18:06 |
RobertBerger | @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 ;) | 18:09 |
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 18:23 | |
dev1990 | ram prices going down | 18:25 |
dev1990 | in 2018/ early 2019 ram was super expensive | 18:26 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 18:26 | |
JPEW | RP: Most of these reproducible issues are because of host tool differences :( | 18:29 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 18:40 | |
*** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 18:42 | |
RP | JPEW: hmm, not good :( Which tool(s)? | 18:51 |
JPEW | RP: makeinfo, and the perl reproduciblity is because of host GCC version | 18:52 |
JPEW | Might be able to patch around the perl one... basically it generates different output based on the host GCC version | 18:52 |
JPEW | 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) | 18:53 |
rburton | JPEW: the libx11 multilib bug i just fixed was due to the host compiler too | 18:53 |
RP | JPEW: I guess we could at least brute force that problem | 18:53 |
RP | mandate a buildtools tarball? :/ | 18:54 |
JPEW | RP: Ya, I think I've had to do that in a few other recipes anyway | 18:54 |
*** mischief <mischief!~mischief@wopr.sciops.net> has quit IRC | 18:54 | |
rburton | we could just export SHELL=/bin/bash... | 18:56 |
rburton | can we actually build without a host bash? | 18:56 |
JPEW | I think in the other cases I just used sed to remove the SHELL line from the makefile | 18:56 |
JPEW | These are the Makefiles used for ptest, not the actual build | 18:57 |
RP | JPEW: as long as it isn't used that should be fine | 18:57 |
JPEW | RP: It hasn't been, but I'll make sure | 18:57 |
*** Guest51996 <Guest51996!~mischief@wopr.sciops.net> has joined #yocto | 18:58 | |
JPEW | 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 | 18:58 |
RP | JPEW: what happened to suddenly expose a load then? :/ | 18:58 |
*** guerinoni <guerinoni!~guerinoni@host16-44-dynamic.181-80-r.retail.telecomitalia.it> has joined #yocto | 18:58 | |
RP | JPEW: M2 build is failing with a load of these failures too :/ | 18:58 |
RP | not as many as that other build mind | 18:59 |
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has joined #yocto | 18:59 | |
JPEW | I'm not sure | 18:59 |
nemgti-og | 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. | 19:01 |
*** guerinoni <guerinoni!~guerinoni@host16-44-dynamic.181-80-r.retail.telecomitalia.it> has quit IRC | 19:01 | |
nemgti-og | 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? | 19:02 |
JPEW | nemgti-og, Traditional SDK or eSDK? | 19:02 |
nemgti-og | traditional | 19:02 |
JPEW | There are post-install scripts you can add to do whatever you want when the SDK is installed | 19:03 |
* JPEW Looks for an example... | 19:03 | |
Guest51996 | is there a way to depend on a recipe only for its side effect of creating packages? | 19:03 |
*** Guest51996 is now known as mischief | 19:03 | |
JPEW | nemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-too | 19:04 |
JPEW | nemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-toolchain_0.1.bb | 19:04 |
nemgti-og | alright. Thanks a lot JPEW ! | 19:05 |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has quit IRC | 19:05 | |
*** nemgti-og is now known as nord | 19:07 | |
*** nord is now known as lichtjahr | 19:07 | |
*** lichtjahr is now known as nemgti-og | 19:07 | |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has joined #yocto | 19:08 | |
*** WillMiles <WillMiles!~Will@209.87.231.80> has joined #yocto | 19:14 | |
*** MeanEngi <MeanEngi!5fa876af@95.168.118.175> has joined #yocto | 19:25 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 19:30 | |
MeanEngi | Hey, am trying to get the example recipe created with `bitbake-layers create-layer` to run but it seems to be ignored | 19:32 |
MeanEngi | https://pastebin.com/GshWUzpb | 19:32 |
MeanEngi | 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 | 19:33 |
MeanEngi | (This is on zeus) | 19:33 |
LetoThe2nd | MeanEngi: not printed, or not logged? | 19:34 |
MeanEngi | LetoThe2nd: It doesn't show in stdout as the result of executing bitbake. Guess that would fall under printed | 19:36 |
MeanEngi | I've tried the "hello world bitbake" example in which same recipe results in output visible | 19:37 |
MeanEngi | "hello world bitbake" - the one where you try to get the barebones structure for bitbake to work. No poky involved | 19:37 |
LetoThe2nd | MeanEngi: yup. have you checked whats in tmp/work/example/0.1/SOMETHINGIDONTREMEMBERRIGHTNOW/temp/log.do_build ? | 19:38 |
LetoThe2nd | and the other logs there too, ofc? | 19:38 |
MeanEngi | Hm... | 19:40 |
MeanEngi | There doesn't seem to be any | 19:40 |
LetoThe2nd | then theres something really wrong. but the directory structure i described is roughly there? | 19:41 |
MeanEngi | Yup https://pastebin.com/7REft8RG | 19:41 |
LetoThe2nd | can you give it a bitbake -c listtasks example? | 19:42 |
MeanEngi | LetoThe2nd: https://pastebin.com/Rmt8eeB8 | 19:45 |
MeanEngi | Nothing much seems to be happening in the recipe: https://pastebin.com/dEPQYeXL | 19:46 |
LetoThe2nd | what happens upon bitbake -c build example ? | 19:48 |
MeanEngi | LetoThe2nd: https://pastebin.com/57GE8Li7 | 19:48 |
LetoThe2nd | and after that, there is still no log for do_build? | 19:50 |
MeanEngi | Nope | 19:50 |
LetoThe2nd | hum. no idea then, sorry. | 19:50 |
MeanEngi | LetoThe2nd: Fair, thanks :) | 19:51 |
LetoThe2nd | 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. | 19:51 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 19:52 | |
MeanEngi | I'll dig a bit and post if something comes up | 19:54 |
*** MeanEngi <MeanEngi!5fa876af@95.168.118.175> has quit IRC | 20:04 | |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has quit IRC | 20:09 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 20:13 | |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has joined #yocto | 20:15 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:23 | |
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 20:24 | |
*** bornjre <bornjre!~manjaro-b@43.231.208.252> has quit IRC | 20:29 | |
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 21:17 | |
*** berton_ <berton_!~berton@177.194.196.4> has quit IRC | 21:18 | |
*** piksu <piksu!575c74e5@87-92-116-229.bb.dnainternet.fi> has quit IRC | 21:31 | |
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has quit IRC | 21:32 | |
*** beratiks <beratiks!b0e9c643@176.233.198.67> has joined #yocto | 21:32 | |
*** dev1990 <dev1990!~dev@asx191.neoplus.adsl.tpnet.pl> has joined #yocto | 21:32 | |
*** rburton <rburton!~rburton@192.198.151.43> has quit IRC | 21:42 | |
*** jrdn__ <jrdn__!b8477076@mail.validmanufacturing.com> has joined #yocto | 21:44 | |
jrdn__ | 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. | 21:46 |
jrdn__ | Do I have any recourse other than updating the src to work with openssl1.1? | 21:47 |
*** pohly <pohly!~pohly@p5B05600C.dip0.t-ipconnect.de> has quit IRC | 21:56 | |
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 21:57 | |
*** jrdn__ <jrdn__!b8477076@mail.validmanufacturing.com> has quit IRC | 22:05 | |
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has quit IRC | 22:13 | |
*** mabnhdev <mabnhdev!0c260e08@12.38.14.8> has quit IRC | 22:28 | |
*** WillMiles <WillMiles!~Will@209.87.231.80> has quit IRC | 22:41 | |
khem | which release are you on | 23:01 |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 23:02 | |
khem | 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 | 23:02 |
JaMa | it's the conflict in RSS (before packages are even created) | 23:06 |
JaMa | whole dependency tree needs to use the same openssl version | 23:07 |
JaMa | I was using openssl10 for everything (from recipe called openssl to prevent incompatible 1.1 version ever leaking into our builds) | 23:07 |
JaMa | until I could get rid of it at least from OSE version in https://github.com/webosose/meta-webosose/commit/d0a436fa08ab7e732845afb07d95ed7e6616a2ae | 23:09 |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 23:15 | |
*** kiwi_29 <kiwi_29!43cf6f8a@gateway/web/cgi-irc/kiwiirc.com/ip.67.207.111.138> has joined #yocto | 23:18 | |
kiwi_29 | 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" | 23:18 |
kiwi_29 | after doing that I see psplash when I do "bitbake -g core-image-minimal && cat pn-buildlist |grep 'psplash' " | 23:19 |
kiwi_29 | however the image does not seem to have this package | 23:19 |
kiwi_29 | also the package is not seen in the manifest file of the image inside tmp/deploy/images/<architecture>/imagename.manifest | 23:19 |
kiwi_29 | 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 | 23:19 |
*** develonepi3 <develonepi3!~devel@2600:1700:69f0:42c0::a> has quit IRC | 23:32 | |
*** develonepi3 <develonepi3!~devel@2600:1700:69f0:42c0::a> has joined #yocto | 23:38 | |
*** PaowZ <PaowZ!~Vince@193.252.149.222> has quit IRC | 23:39 | |
*** PaowZ <PaowZ!~Vince@193.252.149.222> has joined #yocto | 23:39 | |
creich | kiwi_29: there are several possible points to check | 23:55 |
creich | e.g. you could check your build/tmp/work/ if there is any folder with the name of the package -->$ find <YOURPATHTOBUILD>/build/tmp/work/ -iname "*NAME-OF-PACKAGE*" | 23:57 |
creich | check if it's a subfolder of the architecture you're building for. | 23:57 |
creich | kiwi_29: also you could post a build log of -->$ bitbake -f psplash | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!