**** BEGIN LOGGING AT Thu Jun 18 02:59:57 2020 Jun 18 08:01:53 silviof: you might want to have a look at PREFERRED_VERSION_ to pick a version of a recipe. Because IIRC, the recipe which appears in the layer with the highest priority will win whatever its version number is. Jun 18 08:01:57 silviof: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#prioritizing-your-layer Jun 18 08:03:23 also, accoridng to this paragraph, the first .conf or bbclass to be found in BBLAYERS is taken, no priority taken into account. So you might want to have your conf files named differently (which i assume is for a machine in which case it's a good idea to have a different name than from upstream) Jun 18 08:05:28 @all: just to be extra super duper sure about my intuition.. when recipe A "require recipes-foo/foo/foo_1.2.bb", no bbappend (if they exist) for foo_1.2.bb will be applied when resolving the require, right? Jun 18 08:05:35 qschulz: Thank you, yes the last clue is how I will proceed. Jun 18 08:06:13 silviof: if it's something you think would benefit all users, send a patch to add your needs to the original conf file :) Jun 18 08:23:16 So no-one can clarify the usage on "/lib64/ld-linux-x86-64.so.2" in a non-multilib build ? Jun 18 08:23:56 yann: could it be a leftover from where you migrated to multilib to non multilib Jun 18 08:24:03 when* Jun 18 08:25:32 what kind of leftover are you thinking about ? Jun 18 08:31:39 I see a BASE_LIB_tune-dbfp4 = "lib64", but then it does not look more harmful than BASE_LIB_tune-x86-64 = "lib64" - it even looks completely redundant with the latter Jun 18 08:32:30 and "bitbake -e glibc" shows BASELIB="lib" in the end Jun 18 08:34:59 yann: try without sstate-cache from a fresh repo and check if the symlink is still there? (you can look now with oe-pkgdata-util find-path to find exactly which package has this symlink Jun 18 08:35:01 "bitbake -e glibc" indeed shows no variable with "lib64" in it, apart from unused overrides and BASE_LIB_tune-*, and the functions only use it in tests Jun 18 08:35:16 build the recipe building this package (glibc I guess) only, it shouldn't take that long from a clean sstate-cache Jun 18 08:35:27 I had nuked the sstate-cache already when I switched Jun 18 08:36:13 and the tmpdir and everything? Jun 18 08:37:09 there is no symlink originally (*I* added one trying to fix the problem) - the thing I'm after is why when BASEDIR="lib" ld.so does this "/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2" redirect Jun 18 08:38:15 (and why this redirection apparently does not work) Jun 18 08:40:52 for why the redirection does not work: I've seen some code (don't remember where) not following symlinks when looking for a file Jun 18 08:41:20 (not talking about anything close to your problem but jsut so you know, it alreayd happened to me a while ago) Jun 18 08:42:35 qschulz: but there is no symlink in the default setup, just this redirection inside ld.so - I added the symlink afterwards to try to override that redirection, with no effect Jun 18 08:43:14 I'll try to play with glibc and see it I can make any sense of this Jun 18 09:01:14 hi, I added a partition in the wks file, but bitbake seems to ignore the modification when I ask it to rebuild the image. can I force bitbake to rebuild the SD card image somehow? Jun 18 09:02:03 qschulz: it' still quite surprising, that "strings /lib/ld-linux-x86-64.so.2 |grep lib64" turns out empty Jun 18 09:02:39 as well as /etc/ld.so.* Jun 18 09:03:27 yann: I really don't understand what you mean by 'ld.so does this "/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2" redirect' but I'm also absolutely not knowledgeable in that area :/ Jun 18 09:06:14 when I ldd on an exe that has "/lib64/ld-linux-x86-64.so.2" as interpreter, ldd shows "/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2" : that basically seems to mean that it resolved the absolute path to a different one (which does exist); and despite this launching that exe has the exact symptom of interpreter not found Jun 18 09:12:41 hm, it seems more complicated: if I try a simpler exe (/bin/echo from Debian), it does work when the symlink is there Jun 18 09:13:57 yann, does readelf on the exe show the same interpreter ? Jun 18 09:16:54 kroon: yes Jun 18 09:17:48 if I stick with "echo", and I remove the /lib64/ld-linux-x86-64.so.2 I created, ldd still shows me the rewrite to /lib/ but then the exe does not load Jun 18 09:29:25 I even rebooted to an image without the /lib64 directory entry, and I have the same issue: the lib64 echo won't run, despite ldd saying otherwise - unless I add an explicit symlink like Debian did. But the, the real-life monster of an electron app, OTOH, still won't work Jun 18 09:39:33 a quick test in a small chroot on my debian box does not show such a rewrite - rather more sanely, "LD_TRACE_LOADED_OBJECTS=1 /bin/echo" fails with ENOENT until I create the symlink Jun 18 09:40:00 would it be the kernel ELF handler playing this trick ? Jun 18 10:12:38 so back to multilib for now, testing RP suggestion to deal with https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937 Jun 18 11:44:35 hey, short question: I have seen DEPENDS += and also RDPENDS_${PN} = in recipes. I understand that DEPENDS != RDEPENDS. My question is: are they handled differently as in is DEPENDS package specific by default and RDEPENDS needs that _${PN} to not pollute the globals? Jun 18 11:45:25 sven^: they are not handled differently, they are fundamentally different. Jun 18 11:46:04 Letothe2nd: .. because DEPENDS is used in an isolated build environment while RDEPENDS influences the resulting image? Jun 18 11:46:56 sven^: in a nutshell, DEPENDS refers to something that the recipe needs to be built. note: "recipe", hence for at least *one* of the packages it produces, but there's not distinciton. RDEPENDS on the other hand tells the package manager that a specific package (namely, ${PN} in the canonical case) needs something else to also be installed in the image. Jun 18 11:47:17 ok, got it Jun 18 11:47:47 sven^: its very well possible that only one of the resulting packages of a recipe need an RDEPENDS, while all others do not. in fact, thats a pretty common case. Jun 18 11:49:57 (kind of) follow-up: it seems sometimes RDEPENDS is resolved automatically and sometimes I need to state it explicitly. Is there a reason for this and should I always explicitly state it? (e.g. I think I have custom recipes containing bash scripts that just "work" and others where I get QA errors) Jun 18 11:52:08 sven^: AFAIK they never should be resolved automagically, so you're probably overlooking something. Jun 18 11:52:52 Letothe2nd: ok, I just checked a few recipes while waiting for your answer and found the RDEPENDS hidden away right at the top Jun 18 11:52:58 so I guess you are right. Jun 18 11:53:01 :) Jun 18 11:53:02 Thanks for your help d) Jun 18 11:53:13 throw money! throw money! Jun 18 11:54:02 sven^: if your recipe A have a DEPENDS on recipe B and one of the libraries from A specifies it requires a specific lib, if this lib is part of a package from recipe B, RDEPENDS will be automagically filled Jun 18 11:54:21 this is common Jun 18 11:54:38 hmm Jun 18 11:54:41 makes sense Jun 18 11:54:48 throw money where? At my screen? Jun 18 11:55:07 sven^: please do so! and post pictures. Jun 18 11:55:31 mid throwing? Don't think I'll be quick enough for that Jun 18 11:56:36 awww.... try for me? pretty please! Jun 18 11:56:46 oh, should I do RDEPENDS_${PN} += or simple =? It should be empty, shouldn't it? Jun 18 11:58:31 tried 3 times. Failed. Giving up Jun 18 11:58:41 i would go for +=, just out of habit. there might be cases when a class already prefills it. Jun 18 11:58:44 sven^: :( Jun 18 12:40:31 sven^: we'll need more than "Failed." to help you :) Jun 18 12:41:05 qschulz: guess he was referring to the picture-of-money-throwing joke :/ Jun 18 12:42:11 well, I tried to throw the coins with my right hand and held my phone with the left hand. I pushed the "photo" button up to approx. 1.5 seconds before letting go of the coin. I saw the coin flashing by on the phone's screen but it was never in the resulting pictures Jun 18 12:42:33 Letothe2nd: me = https://media.giphy.com/media/mEahVAkKjt0VL2o5Jk/giphy.gif Jun 18 12:49:51 constructive criticism on my technique is always appreciated Jun 18 12:50:41 sven^: i constructively suggest to call ARRI and rent a high speed cam Jun 18 12:53:41 you'll have to throw some money at me first. No photographs required Jun 18 12:56:45 awww :( Jun 18 13:12:40 ee anyone remember the package name for `file`? Jun 18 13:13:56 milloni: coreutils? Jun 18 13:14:11 thanks Jun 18 13:14:58 milloni: oe-pkgdata-util find-path /usr/lib/file? Jun 18 13:15:21 qschulz: useful, thanks Jun 18 13:15:22 milloni: i was just guessing, in doubt use qschulz' advice. Jun 18 13:34:34 $ dpkg -S $(which file) Jun 18 13:34:35 file: /usr/bin/file Jun 18 13:34:39 milloni: ^ Jun 18 13:56:35 neverpanic yeah but thats for debian/debian-derived right? Jun 18 13:59:45 neverpanic: very good point. Jun 18 13:59:59 milloni: he hinted that i was wrong, and this applies: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/file/file_5.38.bb?h=master Jun 18 14:00:02 Yes, but generally various distributions have similar naming for the various upstream packages. For example, you can follow links into the debian tracker: https://tracker.debian.org/pkg/file Jun 18 14:00:19 That then has a 'homepage' link on the right which points to upstream at https://www.darwinsys.com/file/ Jun 18 14:13:32 ok, thanks everyone Jun 18 14:20:09 Can anyone help my with meta-anaconda...It manual tells the following: Jun 18 14:20:10 3.2.4 Prepare installer build. $ . /oe-core/oe-init-build-env The build requires DISTRO = "anaconda", location of target build and recipe name of target image. Edit conf/local.conf to use: $ echo 'PACKAGE_CLASSES = "package_rpm"' >> conf/local.conf $ Jun 18 14:20:11 echo 'DISTRO = "anaconda"' >> conf/local.conf $ echo 'INSTALLER_TARGET_BUILD = ""' >> conf/local.conf $ echo 'INSTALLER_TARGET_IMAGE = "core-image-minimal"' >> conf/local.conf Jun 18 14:21:36 I have give the as /build/ but somehow when I boot from it....it starts the anaconda installer and then gives an error stating an unknown error has occurred...It stops at the page for selecting County in the background Jun 18 14:30:22 rburton: are you happy now? ;-) Jun 18 16:34:00 is there any way to tell dnf to skip checking a specific package for linking consistencies when installing it? i.e. there's a black-box prebuilt binary to be installed into an image, INSANE_SKIP disables bitbake QA checks on packaging, but dnf then refuses to install the resulting package into an image. any hints? Jun 18 16:40:20 what is the error? Jun 18 16:40:46 some errors can be ignored, some can't.. so I need specifics Jun 18 16:41:46 fray: nothing provides libblah.so.1.2.3()(64bit) needed by package Jun 18 16:42:15 No, that can't be skipped AFAIK. You will need to provide that in the package. You can set a manual provide though, let me look up the syntax Jun 18 16:42:53 You might be able to prevent bitbake from writing that dependency into the package using some clever setting for PRIVATE_LIBS Jun 18 16:43:03 Ahh yes, that might work.. Jun 18 16:45:06 FILERPROVIDES__append = "libblah.so.1.2.3()(64bit)" Jun 18 16:45:21 the dfile bit I'm not sure what is is.. you may have to use bitbake -e to find the exact value to use.. Jun 18 16:45:42 FILERPROVIDESFLIST_ will have a list of the files in that package Jun 18 16:46:06 ah, interesting. thanks! Jun 18 16:46:14 then you just have to set that on whatever provides that thing.. Jun 18 16:46:47 but the fact it wasn't automatic makes me suspicious it's broken, unless it just doesn't live in a standard lib path or something Jun 18 16:49:54 fray: well, no, it is a broken dependency, which is expected and to be handled at run-time. just need an override for the binary with such missing dependency to be installed upfront Jun 18 17:07:04 Ohh.. that is different.. Jun 18 17:07:12 you want to SKIP the filedeps then, most likely Jun 18 17:07:26 SKIP_FILEDEPS_ = '1' Jun 18 17:07:59 but if there are other things that should have file deps, then there is no mechanism to only do partial Jun 18 17:31:35 fray: great, SKIP_FILEDEPS works! btw - https://git.openembedded.org/openembedded-core/commit/?id=8c4dcdfa9d5a37acb6f492b1cf0e40a403e5fbe9 :) Jun 18 17:43:18 denix: SKIP_FILEDEPS will just defer the problem from build time to runtime afaik Jun 18 17:43:28 in this case Jun 18 17:44:53 this commit you points out will result in similar runtime failures for test scripts needing ksh and system not having it. so its a calculated risk Jun 18 17:45:09 khem: that's what needed Jun 18 17:46:14 runtime problem will be obscure Jun 18 17:46:23 from above - fray: well, no, it is a broken dependency, which is expected and to be handled at run-time. just need an override for the binary with such missing dependency to be installed upfront Jun 18 17:47:54 how is it handled at runtime ? Jun 18 17:48:24 btw, this is specific to rpm, as ipk does allow such packages Jun 18 17:48:32 there should be some provider for it I guess and you will know that at build time no ? Jun 18 17:49:01 yeah I think thats one thing thats good about rpm everything else is meh Jun 18 17:49:22 heh, I'm not that familiar woth rpm Jun 18 17:51:27 it's a black box prebuilt binary with whole bunch of INSANE_SKIP flags to bypass build-time/packaging QA tests - so it's already known to not adhere to the rules :) Jun 18 17:51:56 specifically "file-rdeps", so bitbake already known about missing rdepends. but rpm needs to be told separately Jun 18 18:04:32 bad package I guess Jun 19 01:58:38 any ideas why the git fetcher might be writing over my working tree? **** ENDING LOGGING AT Fri Jun 19 02:59:57 2020