Wednesday, 2020-01-22

*** goliath <goliath!> has quit IRC00:02
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto00:11
mischiefalso, im confused by how kernel-module-split and RPROVIDES works00:18
mischiefif recipe creates kernel-module-foo and i add kernel-module-foo to RDEPENDS, how does bitbake know that makes kernel-module-foo if wasn't also added to RDEPENDS?00:19
*** ericch <ericch!> has quit IRC00:22
creichmischief: i am not sure, but as far as i understood, 'require' and 'MACHINE_FEATURE' are not achiving the same thing!00:23
creichrequire 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
mischiefcreich: i have a simple case - i want to MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-foo" and KERNEL_MODULE_AUTOLOAD += "foo"00:25
creichso e.g. if you write some recipe and split it in some kind of generic part like and some version specific part like you can make the .inc a requirement within the bb file00:25
mischiefshould 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
creichi still feel that you kind of mix up two concepts here00:27
creichwether or not you put it in an .inc is part of your development process.00:27
creichsince i am not sure how to handle kernel_modules, i can not really help with the other thing, sorry00:28
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC00:37
*** dev1990 <dev1990!> has quit IRC00:55
*** inf <inf!~informati@unaffiliated/informatic> has quit IRC00:59
*** inf <inf!~informati@unaffiliated/informatic> has joined #yocto01:00
creichok, 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
creichso 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
creich2) 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 folder01:02
creichthx in advance :)01:02
*** dreyna <dreyna!> has joined #yocto02:07
*** dreyna <dreyna!> has quit IRC02:08
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9d1b:2c63:9ae4:da9e> has joined #yocto02:09
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9d1b:2c63:9ae4:da9e> has left #yocto02:11
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC02:16
*** armpit <armpit!~armpit@> has quit IRC02:22
*** davisr <davisr!> has quit IRC02:28
khemperhaps show the code which is failing can give better idea02:59
*** mario-goulart <mario-goulart!> has quit IRC02:59
khempoky 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 distro03:00
*** hpsy <hpsy!~hpsy@> has quit IRC03:43
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has joined #yocto04:51
*** vmeson <vmeson!> has quit IRC05:09
*** vmeson <vmeson!> has joined #yocto05:10
armpitzeddii, have you seen this fix?
*** sgw1 <sgw1!~sgw@> has joined #yocto05:39
*** milloni_ <milloni_!> has joined #yocto05:41
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has quit IRC05:41
*** sgw <sgw!~sgw@> has quit IRC05:41
*** freanux <freanux!~freanux@unaffiliated/freanux> has quit IRC05:41
*** milloni <milloni!> has quit IRC05:41
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has joined #yocto05:43
*** mario-goulart <mario-goulart!> has joined #yocto06:17
*** mmadej <mmadej!> has joined #yocto06:20
*** stuom1 <stuom1!3eecd81d@> has quit IRC06:22
*** AndersD <AndersD!> has joined #yocto06:24
*** stuom1 <stuom1!3eecd81d@> has joined #yocto06:34
*** ThomasD13 <ThomasD13!> has joined #yocto06:53
*** agust <agust!> has joined #yocto07:04
ThomasD13Hi, 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
LetoThe2ndThomasD13: i take it that you have already watched ?07:11
ThomasD13When I build this cmake project here, I have no problems. When I build the recipe with yocto, I got an error during do_compile:
ThomasD13LetoThe2nd, no I did not yet. I watched the first two, and the 7 or 8. video from you07:13
LetoThe2ndThomasD13: 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
ThomasD13However, Yocto says it cannot find "rfal_lib" which is "B" in my example07:13
LetoThe2ndThomasD13: no, its not yocto saying that. this is cmake barfing out on you getting the linkage wrong07:14
LetoThe2ndThomasD13: check against
ThomasD13LetoThe2nd, okay - That was my question now: So its basically a problem to provide a package which has only "internal" dependencies?07:14
LetoThe2ndplease see video :)07:15
ThomasD13alright ;)07:15
erboThomasD13: 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!> has quit IRC07:20
*** frsc <frsc!> has joined #yocto07:32
ThomasD13erbo, locally I just invoked "make". So nothing parallel. This is for "B" (rfal_lib):  This is for "C":
ThomasD13Without 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 systemwide07:46
ThomasD13And then watch the video ;)07:46
LetoThe2ndThomasD13: 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
LetoThe2ndso my first and foremost guess is that your library dependencies inside CMakeLists.txt are off.07:48
ThomasD13LetoThe2nd, 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 yocto07:54
erboI agree with LetoThe2nd, this is most likely a CMakeLists issue07:54
ThomasD13Don't get me wrong, I hope also this is a CMakeList problem. I guess thats much easier to fix as something with yocto07:55
erboThomasD13: Since you didn't use parallel make, maybe you're lib is always built before the app.07:55
*** pohly <pohly!> has joined #yocto07:55
ThomasD13erbo, I think the lib must be built before the app, since it's linked to it07:55
erboThomasD13: of course, but did you state that in the CMakeLists file?07:56
*** TobSnyder <TobSnyder!> has joined #yocto07:57
erboYou can try building the recipe without parallel make by disabling it in the recipe: PARALLEL_MAKE = ""07:58
erboBut I suggest you don't use that as a solution, better to solve it properly, but it could help verify that this is the issue07:58
*** guerinoni <guerinoni!> has joined #yocto08:00
ThomasD13erbo, 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
erboThomasD13: do you have a top-level CMakeLists which uses the other two?08:00
*** yacar_ <yacar_!> has joined #yocto08:00
ThomasD13erbo, this is it:
*** hpsy <hpsy!~hpsy@> has joined #yocto08:03
erboThomasD13: I'm no CMake expert, but I think something like "add_dependencies (exampleNFC rfal_lib)" in the apps CMakeLists might solve it08:04
ThomasD13erbo, I'll check that, thank you very much.08:05
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:07
*** hpsy <hpsy!~hpsy@> has quit IRC08:11
*** hpsy <hpsy!~hpsy@> has joined #yocto08:12
*** lucaceresoli <lucaceresoli!> has joined #yocto08:41
ThomasD13LetoThe2nd, just curious about your libanswer ( You linked answer to your application ask. Did you specify in the recipe RDEPENDS = or something? Or might this be answered in that video?08:45
LetoThe2ndThomasD13: 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
ThomasD13Okay, 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 problem08:52
LetoThe2ndThomasD13: 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
LetoThe2ndand 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
ThomasD13LetoThe2nd, 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. Thats08:57
ThomasD13why I want to google first08:57
LetoThe2ndThomasD13: 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
LetoThe2ndThomasD13: 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!> has joined #yocto09:00
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto09:14
*** goliath <goliath!> has joined #yocto09:17
*** jklare <jklare!~jklare@> has quit IRC09:19
yoctiNew news from stackoverflow: Yocto packagegroup install <>09:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:28
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:32
*** yacar_ <yacar_!> has quit IRC09:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:34
*** dexterlb <dexterlb!> has quit IRC09:40
LetoThe2ndsession #10 uploaded 12hrs ago, already >60 views on YT09:40
* LetoThe2nd enters full rockstar mode!09:40
nrossiLetoThe2nd: time for a promotion to LetoTheGreat? :)09:43
LetoThe2ndnrossi: i am already god emperor of the known universe. hard to be promoted any further.09:44
qschulzLetoThe2nd: last yocti message: isn't it the same thing as yesterday? i.e. CORE_IMAGE_EXTRA_INSTALL and not IMAGE_INSTALL?09:44
nrossiLetoThe2nd: time to expand to the multi-verse :)09:44
LetoThe2ndnrossi: hehe09:44
LetoThe2ndqschulz: no iea.09:45
qschulzLetoThe2nd: I sent a comment, we'll see :)09:48
*** rburton <rburton!Adium@nat/intel/x-odlakjtmrsarrfyl> has joined #yocto09:51
*** rburton <rburton!Adium@nat/intel/x-odlakjtmrsarrfyl> has quit IRC09:54
*** yacar_ <yacar_!> has joined #yocto09:59
*** tprrt <tprrt!~tprrt@> has joined #yocto10:00
erboqschulz: I think it looks correct, but I also added a comment with an idea10:16
qschulzerbo: mmm good point as well, I always forget about this renaming of packages if they only contain a lib10:50
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC10:53
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto10:56
*** bornjre <bornjre!~manjaro-b@> has joined #yocto11:10
creichqschulz: 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@> has quit IRC11:12
creichanyway, i found that it wasn't about the IMAGE_INSTALL at all. it was a bug in the Makefile11:12
*** yacar_ <yacar_!> has quit IRC11:12
creichfor 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
creichi 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!> has joined #yocto11:14
*** goliath <goliath!> has quit IRC11:17
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has quit IRC11:34
*** armpit <armpit!~armpit@2601:202:4180:a5c0:682c:76b9:6d8a:bbd2> has joined #yocto11:36
*** dexterlb <dexterlb!> has joined #yocto11:38
*** dev1990 <dev1990!> has joined #yocto11:48
*** guerinoni <guerinoni!> has quit IRC11:49
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/> has joined #yocto11:53
*** goliath <goliath!> has joined #yocto11:57
*** berton <berton!~berton@> has joined #yocto11:59
*** tgamblin <tgamblin!> has quit IRC12:00
stuom1When 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@> has quit IRC12:06
*** yacar_ <yacar_!> has joined #yocto12:09
Ad0is there a way to have layers conditionally defined based on distro/image/machine ?12:11
Ad0I remember I googled before but I forgot the results :/ was something related to filter and machine I think12:12
*** berton <berton!~berton@> has quit IRC12:13
*** berton <berton!~berton@> has joined #yocto12:14
stuom1ohh maybe my problem is connected to that missing sstate optimizations mentioned in the docs12:18
stuom1is there some way around that or i just need to live with it?12:20
LetoThe2ndstuom1: do you have seperate tmpdirs as you ought to?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
dl9pfWho deals with the YP main website ? shows 3.0.1 , but is still 3.0.012:23
stuom1this gives me the idea that maybe i shouldnt have two tmpdirs, but elsewhere it was suggested to keep separate12:23
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto12:25
dev1990hi, 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
dev1990and rpm stage failing to do package12:34
creichhi 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
dev1990only ${S}/cht/ contains characters "[" "]"12:36
creichto 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
creichmy bbappend:
dev1990first approach was to use cp but this also failing at rpm stage12:37
creichand my output:
creichdev1990: do the file_names_ contain that character or the files itself?12:38
dev1990file names contain this characters12:39
creichdev1990: did you get some error that you could post?12:40
dev1990yes, sec12:40
creichtypially those brackets are special characters to terminals, which might cause your problem12:40
dev1990well, repository store those files I had no choice but to copy them as is12:42
creichi got that, just tried to point out the direction of your problem :)12:43
creichstill, please share a log if you can :)12:43
dev1990I'll prepare log shortly, some packages are recopiling right now, becasue I'm heavli using ${AUTOREV} in most of recipes12:44
creichhave you ever tried copying that stuff manually?12:44
ThomasD13LetoThe2nd, according time stealing: "some QA issues" - that was not a question or request for help. Just a statement.12:45
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
dev1990for example12:46
dev1990my system encoding is UTF-8, not sure how to progress with that12:48
creichdev1990: going to have some lunch. i'll check your logs later :)12:49
dev1990creich: ok, thanks12:49
*** hpsy <hpsy!~hpsy@> has joined #yocto12:50
*** rburton <rburton!~rburton@> has joined #yocto12:51
rburtoni 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 happening12:51
rburtonRP: you're to blame for opkg-utils depending on bash 95bf5c0bba6e62283f62d95e5869921df43870ee12:55
rburtonRP: make that a recommends?12:55
dev1990in i found lines like12:57
dev1990file = file.replace("[", "?")12:57
dev1990dir = dir.replace("[", "?")12:57
dev1990is this related to my problem with file names that contain "[" or "]" characters ?12:57
rburtonyes probably12:58
RPrburton: why is bash a problem for opkg-build?13:05
RPrburton: if you're building packages you can likely manage bash13:06
dev1990ok, I'm removing those replaces, probably there is reason for that replace in first place, just testing13:06
rburtonRP: must be a dep somewhere, without a gpl2 bash it didn't even finish parsing13:07
RPrburton: hmm. In principle needing bash for opkg-build shouldn't be a huge deal13:08
RPrburton: finding another way around the issue is fine but it was a real problem13:08
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto13:09
rburtonrewriting opkg-build in not-bash might be a better idea :)13:10
*** berton_ <berton_!~berton@> has joined #yocto13:10
*** berton <berton!~berton@> has quit IRC13:13
dev1990ok with removed replaces the situation is worse13:21
dev1990creich: I think I know the answer, rpm backend do not accept those filenames, probably this is fixable but not sure how13:22
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto13:32
*** goliath <goliath!> has quit IRC13: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
LetoThe2ndclementp[m]: sure is.
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.conf13:48
clementp[m]because my HOST arch is the same as the SDK arch13:49
LetoThe2ndclementp[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 #yocto13:55
yoctiNew news from stackoverflow: How to setup syslog in yocto? <>13:57
Ad0is 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 image13:57
LetoThe2ndAd0: not on image. that is certain.13:58
Ad0that's fine13:58
Ad0I was hoping distro would fix it13:58
Ad0if distro_features = this or that13:58
Ad0or distro name13:59
LetoThe2ndAd0: usually thats a good approach, yes.13:59
*** PaowZ <PaowZ!~Vince@> has joined #yocto14:00
LetoThe2ndclosest thing is probably
paulbarkerAd0: Do you mean modify BBLAYERS based on something like distro or image?14:00
paulbarkerThat's not possible14:00
paulbarkerbblayers.conf is parsed and BBLAYERS is iterated before even local.conf is parsed14:01
paulbarkerLet me find the slides I made that cover this14:01
*** goliath <goliath!> has joined #yocto14:01
Ad0ok what about this one. have a base bblayers file template where I produce a final bblayers.conf with the additional layers14:02
Ad0when I do the source init-oe-stuff14:02
paulbarkerAd0: Look at pages 32 & 33 of
paulbarkerAd0: That should work if your init-oe-stuff script is ran before bitbake14:03
paulbarkerThis 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 flag14:04
paulbarkerThat's often not something you can control though if third-party layers are broken - give them a kick14:05
Ad0they have an entirely different layer for production vs demo14:05
Ad0makes it hard to have a SCM friendly structure14:06
paulbarkerYep, that's very wrong!14:06
Ad0check this one
Ad0it tells you to "bitbake-layers remove-layer ../meta-mender/meta-mender-demo14:06
Ad0thanks LetoThe2nd and paulbarker14:07
paulbarker2 or 3 of the Mender devs were in my talk (where those slides are from)14:07
Ad0I am doomed to generate the bblayers.conf entirely14:07
Ad0they should have 1 layer where machine and distro_features decides it instead14:07
paulbarkerRaise an issue, they were interested in fixing it but I think they need it to be clearer that customers do care about this14:07
Ad0the combinations should be able to be fulfilled with for example mender_production, mender_demo as distro features, combined with machine14:08
Ad0or distro features altogether14:08
paulbarkerDefinitely open an issue with them. I'd like to see it fixed myself14:09
Ad0will do :)14:09
Ad0thanks again14:10
Ad0I think I've seen more people doing it in that fashion14:10
*** dexterlb <dexterlb!> has quit IRC14:14
*** RobertBerger <RobertBerger!> has quit IRC14:26
yoctiNew news from stackoverflow: Excluding test folders from python install path <>14:27
*** TobSnyder <TobSnyder!> has quit IRC14:28
*** JPEW56 <JPEW56!cc4da369@> has quit IRC14:30
*** ericch <ericch!> has joined #yocto14:30
mcfriskHi! Any ideas what could be triggering glibc-locales staging failure like this on uptodate zeus:
Saurpaulbarker: 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
paulbarkerSaur: No idea sorry14:39
mcfriskbuildhistory 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.o14:40
mcfriskpackages/aarch64-poky-linux/libgcc/sysroot:-rw-r--r-- -          -                1224 ./usr/lib/aarch64-poky-linux/9.2.0/crtendS.o14:40
mcfrisk(thanks for adding sysroot contents to buildhistory btw!)14:41
ThomasD13Okay, 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
ThomasD13Where do I find more information about what a "dev"-package normally should contain? With this bitbake output I guess it should not contain .so files14:42
LetoThe2ndThomasD13: probably (TM) installing the .so to the proper directory should fix it.14:42
LetoThe2ndThomasD13: so it can get picked up by the packaging mechanism14:43
Saurpaulbarker: 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
ThomasD13Ahh okay, because the .so get picked up by ${PN}-dev, before ${PN}14:43
ThomasD13thanks LetoThe2nd I think I've understood14:44
paulbarkerSaur: 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 backlog14:45
SaurThomasD13: For "normal" versioned DSOs, the symbolic link goes in ${PN}-dev, whiles the link and DSO goes in ${PN}.14:45
SaurThomasD13: 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 sgw14:48
ThomasD13Saur, sorry I have to ask: DSOs = D(?) Shared Objects ?14:49
creichdev1990: hey dev, i am back14:52
creichi saw you found the place within the rpm class14:52
*** RobertBerger <RobertBerger!~rber@2a02:587:3b17:4040:4c07:692c:3325:fe6a> has joined #yocto14:55
dev1990creich: 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
creichdev1990: i am not sure if it's a general problem for rpm packages or only for the bitbake class14:56
creichmaybe you can rename the files during your do_patch phase?14:57
creichdon't know if they have to have those names later..14:57
creichok, let me know if ipk helps14:57
ThomasD13Okay, 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 IRC15:02
*** AndersD <AndersD!> has quit IRC15:02
*** grma <grma!~gruberm@> has quit IRC15:13
*** ThomasD13 <ThomasD13!> has quit IRC15:18
*** stuom1 <stuom1!3eecd81d@> has quit IRC15:23
*** comptroller <comptroller!> has quit IRC15:24
*** RobertBerger <RobertBerger!~rber@2a02:587:3b17:4040:4c07:692c:3325:fe6a> has quit IRC15:29
*** comptroller <comptroller!> has joined #yocto15:34
dev1990creich: ipk working well with that package15:43
*** RobertBerger <RobertBerger!> has joined #yocto15:47
creichdev1990: nice! so you'll stick with ipk i guess?15:52
mcfriskabout 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: < >15:57
dev1990creich: as workaround for now, but I'll file a bug probably.15:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:00
RPmcfrisk: seems odd as that should be the default16:01
creichdev1990: ok. nice that it worked out so far :)16:02
creichjust come here again if you're going to takle the problem again16:02
mcfriskRP: 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!> has quit IRC16:09
*** cpo <cpo!> has quit IRC16:18
*** cpo <cpo!> has joined #yocto16:19
*** piksu <piksu!> has joined #yocto16:32
*** mabnhdev <mabnhdev!0c260e08@> has joined #yocto16:33
mabnhdevI 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 to16:37
mabnhdevreduce my build output size?16:37
*** Bunio_FH <Bunio_FH!> has joined #yocto16:39
*** Bunio_FH <Bunio_FH!> has quit IRC16:40
dev1990creich: ok, thanks :) I just filled a first bug in Yocto Project bugtracker, hope it's correctly filled16:41
yoctiBug 13746: normal, Undecided, ---, unassigned, NEW , Unable to create RPM package from repo that contains filenames with "[" and "]" characters16:41
mabnhdevComparison ofsumo vs zeus build sizes -
qschulzmabnhdev: 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
rburtonmabnhdev: 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
rburtonsurely you don't care about anything apart from deploy/ after the build anyway16:43
rburtonwhich was 8g -> 11g16:44
rburtonstill more than i'd expect, but a lot easier to work out16:44
mabnhdevrburton Default for 'du' is to NOT count hardlinks, no?16:46
creichmabnhdev: 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 there16:47
rburtonmabnhdev: shouldn't be.  of course if you copied that somewhere before counting, links could have been lost16:48
creichusually there are host tools and stuff. maybe you used external toolchains before or something like that?16:49
*** goliath <goliath!> has quit IRC16: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!> has joined #yocto16:57
*** yacar_ <yacar_!> has quit IRC16:58
*** ms_k <ms_k!> has left #yocto16:59
creichsorry, 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
qschulzmabnhdev: if all of them are significantly bigger, try to isolate which recipe populates the sysroot of others with that many files17:01
*** Bunio_FH <Bunio_FH!> has quit IRC17:02
*** pidge <pidge!~pidge@> has joined #yocto17:03
*** hpsy <hpsy!~hpsy@> has quit IRC17:08
*** nslu2-log_ <nslu2-log_!> has joined #yocto17:15
*** lfa <lfa!~lfa@> has quit IRC17: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!> has quit IRC17:17
*** nslu2-log_ is now known as nslu2-log17:17
mcfriskfwiw, 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
mcfriskalso 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 regression17:25
*** frsc <frsc!> has quit IRC17:26
*** hpsy <hpsy!~hpsy@> has joined #yocto17:27
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/> has quit IRC17:31
*** falk0n <falk0n!> has quit IRC17:31
*** falk0n <falk0n!> has joined #yocto17:36
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:38
*** tprrt <tprrt!~tprrt@> has quit IRC17: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
LetoThe2ndRobertBerger: 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
LetoThe2ndOTOH, 8GiB is like, meh, anyways :P18:01
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto18: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!> has joined #yocto18:23
dev1990ram prices going down18:25
dev1990in 2018/ early 2019 ram was super expensive18:26
*** goliath <goliath!> has joined #yocto18:26
JPEWRP: Most of these reproducible issues are because of host tool differences :(18:29
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC18:40
*** AndersD <AndersD!> has quit IRC18:42
RPJPEW: hmm, not good :( Which tool(s)?18:51
JPEWRP: makeinfo, and the perl reproduciblity is because of host GCC version18:52
JPEWMight be able to patch around the perl one... basically it generates different output based on the host GCC version18:52
JPEWAlso, 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
rburtonJPEW: the libx11 multilib bug i just fixed was due to the host compiler too18:53
RPJPEW: I guess we could at least brute force that problem18:53
RPmandate a buildtools tarball? :/18:54
JPEWRP: Ya, I think I've had to do that in a few other recipes anyway18:54
*** mischief <mischief!> has quit IRC18:54
rburtonwe could just export SHELL=/bin/bash...18:56
rburtoncan we actually build without a host bash?18:56
JPEWI think in the other cases I just used sed to remove the SHELL line from the makefile18:56
JPEWThese are the Makefiles used for ptest, not the actual build18:57
RPJPEW: as long as it isn't used that should be fine18:57
JPEWRP: It hasn't been, but I'll make sure18:57
*** Guest51996 <Guest51996!> has joined #yocto18:58
JPEWIt... might take a while to work through these, but as I stated, I don't think any of these are from the INHIBIT_STRIP18:58
RPJPEW: what happened to suddenly expose a load then? :/18:58
*** guerinoni <guerinoni!> has joined #yocto18:58
RPJPEW: M2 build is failing with a load of these failures too :/18:58
RPnot as many as that other build mind18:59
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has joined #yocto18:59
JPEWI'm not sure18:59
nemgti-ogHello 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!> has quit IRC19:01
nemgti-ogNow, 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
JPEWnemgti-og, Traditional SDK or eSDK?19:02
JPEWThere are post-install scripts you can add to do whatever you want when the SDK is installed19:03
* JPEW Looks for an example...19:03
Guest51996is there a way to depend on a recipe only for its side effect of creating packages?19:03
*** Guest51996 is now known as mischief19:03
JPEWnemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-too19:04
JPEWnemgti-og, Look at meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-toolchain_0.1.bb19:04
nemgti-ogalright. Thanks a lot JPEW !19:05
*** bornjre <bornjre!~manjaro-b@> has quit IRC19:05
*** nemgti-og is now known as nord19:07
*** nord is now known as lichtjahr19:07
*** lichtjahr is now known as nemgti-og19:07
*** bornjre <bornjre!~manjaro-b@> has joined #yocto19:08
*** WillMiles <WillMiles!~Will@> has joined #yocto19:14
*** MeanEngi <MeanEngi!5fa876af@> has joined #yocto19:25
*** goliath <goliath!> has quit IRC19:30
MeanEngiHey, am trying to get the example recipe created with `bitbake-layers create-layer` to run but it seems to be ignored19:32
MeanEngiI'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 printed19:33
MeanEngi(This is on zeus)19:33
LetoThe2ndMeanEngi: not printed, or not logged?19:34
MeanEngiLetoThe2nd: It doesn't show in stdout as the result of executing bitbake. Guess that would fall under printed19:36
MeanEngiI've tried the "hello world bitbake" example in which same recipe results in output visible19:37
MeanEngi"hello world bitbake" - the one where you try to get the barebones structure for bitbake to work. No poky involved19:37
LetoThe2ndMeanEngi: yup. have you checked whats in tmp/work/example/0.1/SOMETHINGIDONTREMEMBERRIGHTNOW/temp/log.do_build ?19:38
LetoThe2ndand the other logs there too, ofc?19:38
MeanEngiThere doesn't seem to be any19:40
LetoThe2ndthen theres something really wrong. but the directory structure i described is roughly there?19:41
LetoThe2ndcan you give it a bitbake -c listtasks example?19:42
MeanEngiNothing much seems to be happening in the recipe:
LetoThe2ndwhat happens upon bitbake -c build example ?19:48
LetoThe2ndand after that, there is still no log for do_build?19:50
LetoThe2ndhum. no idea then, sorry.19:50
MeanEngiLetoThe2nd: Fair, thanks :)19:51
LetoThe2ndi 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 #yocto19:52
MeanEngiI'll dig a bit and post if something comes up19:54
*** MeanEngi <MeanEngi!5fa876af@> has quit IRC20:04
*** bornjre <bornjre!~manjaro-b@> has quit IRC20:09
*** Bunio_FH <Bunio_FH!> has joined #yocto20:13
*** bornjre <bornjre!~manjaro-b@> has joined #yocto20:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:23
*** yann <yann!> has quit IRC20:24
*** bornjre <bornjre!~manjaro-b@> has quit IRC20:29
*** tgamblin <tgamblin!~tgamblin@> has quit IRC21:17
*** berton_ <berton_!~berton@> has quit IRC21:18
*** piksu <piksu!> has quit IRC21:31
*** dev1990 <dev1990!> has quit IRC21:32
*** beratiks <beratiks!b0e9c643@> has joined #yocto21:32
*** dev1990 <dev1990!> has joined #yocto21:32
*** rburton <rburton!~rburton@> has quit IRC21:42
*** jrdn__ <jrdn__!> has joined #yocto21: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!> has quit IRC21:56
*** tgamblin <tgamblin!> has joined #yocto21:57
*** jrdn__ <jrdn__!> has quit IRC22:05
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has quit IRC22:13
*** mabnhdev <mabnhdev!0c260e08@> has quit IRC22:28
*** WillMiles <WillMiles!~Will@> has quit IRC22:41
khemwhich release are you on23:01
*** dv_ <dv_!> has quit IRC23:02
khemin 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 ssl23:02
JaMait's the conflict in RSS (before packages are even created)23:06
JaMawhole dependency tree needs to use the same openssl version23:07
JaMaI was using openssl10 for everything (from recipe called openssl to prevent incompatible 1.1 version ever leaking into our builds)23:07
JaMauntil I could get rid of it at least from OSE version in
*** dv_ <dv_!> has joined #yocto23:15
*** kiwi_29 <kiwi_29!43cf6f8a@gateway/web/cgi-irc/> has joined #yocto23:18
kiwi_29hello... 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_29after doing that I see psplash when I do "bitbake -g core-image-minimal && cat pn-buildlist |grep 'psplash' "23:19
kiwi_29however the image does not seem to have this package23:19
kiwi_29also the package is not seen in the manifest file of the image inside tmp/deploy/images/<architecture>/imagename.manifest23:19
kiwi_29what could be can I make sure a package is built. And how can I debug what is wrong and why is the pacakge not building23:19
*** develonepi3 <develonepi3!~devel@2600:1700:69f0:42c0::a> has quit IRC23:32
*** develonepi3 <develonepi3!~devel@2600:1700:69f0:42c0::a> has joined #yocto23:38
*** PaowZ <PaowZ!~Vince@> has quit IRC23:39
*** PaowZ <PaowZ!~Vince@> has joined #yocto23:39
creichkiwi_29: there are several possible points to check23:55
creiche.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
creichcheck if it's a subfolder of the architecture you're building for.23:57
creichkiwi_29: also you could post a build log of -->$ bitbake -f psplash23:58

Generated by 2.17.2 by Marius Gedminas - find it at!