**** BEGIN LOGGING AT Wed Jun 17 02:59:57 2020 Jun 17 06:40:46 RP: It looks as if Merijn didn't answer to your mail but to something he understood as "user error" :) Jun 17 07:04:53 I get the following error when building with WKS_FILE = "mkhybridiso.wks" option in local.conf Jun 17 07:05:03 | mv: cannot stat /build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/deploy-core-image-full-cmdline-image-complete/core-image-full-cmdline-genericx86-64-20200617065924/mkhybridiso*.direct': No such file or directory Jun 17 07:06:34 The image(s) were created using OE kickstart file: /scripts/lib/wic/canned-wks/mkhybridiso.wks Jun 17 07:10:59 Srijan: Could you post the bitbake command you executed and the full output via a pastebin? Jun 17 07:17:04 The full command was bitbake core-image-full-cmdline Jun 17 07:18:35 And the output I see is uploaded here: https://pastebin.com/5iRPu1zp Jun 17 07:19:05 does anyone know where on the yocto hp actually is the documentation on the eclipse plugin? https://www.yoctoproject.org/software-item/eclipse-ide-plug-in/ claims it is in https://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html but that page nowhere mentions the word 'eclipse'...? Jun 17 07:19:47 It gets build if i remove WKS_FILE = "mkhybridiso.wks" from the local.conf.....actually I am trying to build a bootable iso image using wic. Jun 17 07:20:33 nameclash: the eclipse plugin is dead and gone. Jun 17 07:20:52 aoh Jun 17 07:21:06 r.i.p. I never liked eclipse anyway Jun 17 07:21:43 Srijan: Does `/opt/graylog-poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/deploy-core-image-full-cmdline-image-complete/core-image-full-cmdline-genericx86-64-20200617070532/HYBRID_ISO_IMG-cd.direct` exist? Jun 17 07:22:14 Yes it does Jun 17 07:22:15 my ultimate goal was finding any hint on getting qtcreator integrated with eSDK and as I struggled finding info on that, too I recalled that eclipse was mentioned somewhere... Jun 17 07:22:34 Looks like the mv command is looking for a filename matching `mkhybridiso*.direct` but instead the filename wic created is `HYBRID_ISO_IMG-cd.direct`. Not sure why but at least that gives a pointer for where to look Jun 17 07:23:46 so my real question is: is anyone aware of a qtcreator kit or plugin for eSDK? Jun 17 07:24:26 nameclash: once you create one and publish it, there will be. Jun 17 07:27:15 Letothe2nd: that's a very smart answer :) we're currently playing around with a docker based development workflow and if we manage to get this hooked up to qtcreator somehow I'll be happy to share Jun 17 07:28:33 nameclash: please do so. if you are actually putting something out I'm happy to help it getting some publicity. Jun 17 07:29:29 thx Jun 17 07:34:28 Letothe2nd: having said that, I must admit I feel a bit unsure now about the one or the other part of the official yocto docs I'm reading... If the current website still advertises something (eclipse) that's dead and gone, I'm not sure what to think when I read other stuff like docker and crops/extsdk-container... you see where I'm getting at? Jun 17 07:34:43 nameclash: i do see :) Jun 17 07:35:12 nameclash: any particular thing you are worried about? let us know so we can fix it. Jun 17 07:35:16 nameclash: If the Eclipse SDK is still advertised on the website that's a bug Jun 17 07:35:37 I posted the links up there Jun 17 07:35:46 paulbarker: I changed the line in the mkhybrid.wks to part /boot --source isoimage-isohybrid --sourceparams="loader=grub-efi,image_name=mkhybridiso" --ondisk cd --label mkhybridiso and that resolved the issue Jun 17 07:35:57 https://www.yoctoproject.org/software-item/eclipse-ide-plug-in/ Jun 17 07:36:07 nameclash: yeah i'm just looking into that one. Jun 17 07:36:57 paulbarker: But then again when I use wic to build an iso it again comes out to be just 44MB in size which again tells me that the rootfs is not getting attached Jun 17 07:37:24 ndec: ping - who can make the eclipse plugin disappear here: https://www.yoctoproject.org/software-overview/project-components/ Jun 17 07:37:46 Letothe2nd: cool, thx Jun 17 07:38:17 Srijan: I guess the mkhybridiso.wks file isn't well tested right now. If you get it working please send patches to the list. If you can't get it working please file a bug Jun 17 07:41:35 paulbarker: Thanks, Paul. Surely will try to get it running Jun 17 07:41:57 nameclash: qtcreator, one of the best IDE I've been using.. Jun 17 07:45:43 Is there any other way to create a bootable iso....so that I can boot image on a vmware Jun 17 07:46:18 PaowZ_: not sure if you're trolling, I'm not that UI dev and try to avoid UI related tickets as much as I can :) but my colleagues that are making heavy use of qtcreator have a better yocto SDK integration on their wishlist so that's why I'm looking into it... Other than that I have no emotional bindings to it :) Jun 17 08:26:57 nameclash: I'mo not trolling.. I wrote a ssh mod for QtCreator and some fixes for target deployment.. Jun 17 08:27:45 I'm fond of ctrl-k shortcut ! Jun 17 08:36:30 PaowZ_: what does it do? Jun 17 08:43:35 there's a "4 months" idle time for poky on cgi, I'm wondering what does it watch Jun 17 08:44:01 mihai-: ? Jun 17 08:44:18 seems like zeus-next is 4 months idle Jun 17 08:44:32 Letothe2nd, https://git.yoctoproject.org/cgit/cgit.cgi/ Jun 17 08:44:32 mihai-: hum yes, why not? Jun 17 08:45:55 mihai-: as far as i can tell, the only relevant -next branch is master-next Jun 17 08:46:41 Letothe2nd, yes, true, but cgi is looking at something else :) Jun 17 08:47:01 I was sorting by idle times to see what layers got updates lately Jun 17 08:47:08 but I guess that's broken Jun 17 09:11:54 RP: progress with g-i issue - it's a build race due to missing dependency Jun 17 09:12:56 kanavin_home: gobject-introspection? Jun 17 09:14:45 kanavin_home: I definitely do not have the context but I had a race in it as well. I was lazy to send a patch but I've one ready. I have a diff for it, I just haven't written a proper commit log yet Jun 17 09:19:38 PaowZ_: I'd also be interested in details on your qtcreator stuff, do you have it somewhere on github to look at? Jun 17 09:21:57 kanavin_home: RP: sent the diff in an answer to a BUG mail I sent a while ago (didn't open a bug report in bugzilla because I wanted to debug it on my own and send a patch and nobody seemed affected at that time (only reproducible with icecc enabled)) Jun 17 09:22:15 I added both of you in Cc Jun 17 09:22:48 "[BUG] icecc breaks gobject-introspection do_compile on 2.7.2 and master" is the mail subject Jun 17 09:23:19 qschulz: I did not receive any mail Jun 17 09:23:52 the gmail address? Jun 17 09:24:02 alex.kanavin@gmail.com Jun 17 09:24:05 (I've sent it jsut now) Jun 17 09:24:46 qschulz: YES Jun 17 09:24:48 that's the issue Jun 17 09:25:14 kanavin_home: I feel so bad, I'm so sorry Jun 17 09:26:04 It's non applicable to upstream gobject-introspection because it comes from one of the wrapper script we add in the recipe (inone of the tasks) Jun 17 09:27:22 qschulz: actually no, it should be sent upstream, as the wrapper logic is upstream too Jun 17 09:28:00 (I got it accepted recently after a very long time spent in an open merge request) Jun 17 09:28:07 kanavin_home: good to have a lead! :) Jun 17 09:28:08 kanavin_home: why is it constructed in one of the tasks then? (I don't have access to my notes at work unfortunately :/) Jun 17 09:28:32 kanavin_home: ah! Good to hear, then can be upstreamed too :) Jun 17 09:29:21 qschulz: the wrappers are custom and not upstream but the logic to use them is upstream Jun 17 09:29:36 nameclash: Well.. back then, I was not pushing my work to upstream.. this was more of a quick win because I needed to reach out target from within QtCreator through SSH.. However, I don't get why no SSH plugin is still out there for this IDE.. as it is so much convenient.. Jun 17 09:30:07 qschulz: since the missing dep is inside that logic, the fix should be submitted Jun 17 09:31:02 I can do that quicker than you perhaps, but you'll not get credit then Jun 17 09:33:07 kanavin_home: An additional Co-developed-by/Signed-off-by is enough for me. The point is to get the issue fixed. And you'll probably write a much better explanation in the commit log :) Jun 17 09:33:34 kanavin_home: in other words, just add the Co-developed-by/Signed-off-by and go for it :) Jun 17 09:34:33 kanavin_home: I know I have two AUH fails. FWIW the patchelf one should be easy as our patches are upstream, WR are helping with qemu Jun 17 09:34:36 Letothe2nd: mihai- : right, it looks odd, will check with the right folks. Jun 17 09:35:08 ndec: i'm more concerned about the eclipse plugin still being linked, thats certainly confusing. Jun 17 09:35:23 qschulz: g-i upstream does not use signed off by Jun 17 09:35:34 Letothe2nd: yeah.. i was about to reply to that one too! Jun 17 09:35:40 ndec: :) Jun 17 09:35:50 qschulz: or actually they don't mind when someone sign offs, so I'll add you Jun 17 09:35:50 kanavin_home: mention by name in the commit message? Jun 17 09:35:50 I can update the website, just need to make sure that RP is ok with the change. Jun 17 09:36:10 :) Jun 17 09:36:24 RP, for the context "09:37:23 ndec: ping - who can make the eclipse plugin disappear here: https://www.yoctoproject.org/software-overview/project-components/" Jun 17 09:36:24 ndec: what is the question? :) Jun 17 09:36:31 I know you :) Jun 17 09:36:55 RP: right, I had to restart AUH manually though because the scheduled run got interrupted by something in the middle of it Jun 17 09:37:05 ndec: yes, lets remove that. Sad but correct Jun 17 09:37:28 kanavin_home: not sure how it would get interrupted :/ Jun 17 09:37:30 RP: time to cue https://youtu.be/A8MO7fkZc5o again. Jun 17 09:38:08 Letothe2nd: indeed Jun 17 09:38:15 kanavin_home: RP: works for me :) Thx for doing it "for me", should have taken the time earlier. I'll try to stop postponing that much patches to send :) Jun 17 09:39:02 kanavin_home: when you're done with that failed builddir can you delete it please? Jun 17 09:39:26 RP: Letothe2nd : looks like we have an 'archive' component on that page. I suppose I should move it down there, right? Jun 17 09:39:37 RP: sure, I can delete it now actually. Jun 17 09:39:42 it's not like we want to erase it completely from the web! Jun 17 09:40:22 ndec: aww... but you know i like destroying/erasing stuff! Jun 17 09:40:41 right. that's why i am asking RP as well ;) Jun 17 09:41:32 kanavin_home: thanks Jun 17 09:41:46 well, it's in the 'archive' section now. that looks good to me.. Jun 17 09:41:50 ndec: yes, archive is appropriate Jun 17 09:42:33 kanavin_home: that has to be the shortest AUH report I've ever seen :) Jun 17 09:42:35 kanavin_home: FWIW should be a backport candidate for still maintained versions of yocto too Jun 17 09:42:43 Letothe2nd: ok, so it's done now. Jun 17 09:42:47 mihai-: \m/ Jun 17 09:44:59 RP: yep, my mega update bombs are bearing fruit ;) Jun 17 09:45:24 kanavin_home: its lovely to see! I'll get patchelf sorted out. Bind is already in -next :) Jun 17 09:45:57 RP: bind 9.11.latest is in next, but 9.16 is not Jun 17 09:46:33 (9.11 update is still beneficial for backporting to stable, but we should ping Armin to rebase and resend the 9.16 too) Jun 17 09:46:48 he had a patch back in the spring, but it had issues, and was just too late in the cycle Jun 17 09:47:05 kanavin_home: make love not bombs! Jun 17 09:47:18 those are bombs of love peace and understanding Jun 17 09:48:03 kanavin_home: bombing is for peace like.... Jun 17 09:48:55 Letothe2nd, cool :) Jun 17 09:49:38 mihai-: i actually meant nico, but :) Jun 17 09:50:18 is this the inception of a "yocto coding mood" radio streaming? Jun 17 09:50:31 oh well :)) Jun 17 09:51:13 huh? Jun 17 09:53:16 sad but true Jun 17 09:56:01 RP: that people do not act on AUH emails remains a problem though. Let's wait and see a few days, but I think we should start placing oe-core list for some entries in maintainers.inc Jun 17 09:56:26 I have already adjusted AUH emails to not be personal Jun 17 10:00:29 qschulz: RP: that was quick :) https://gitlab.gnome.org/GNOME/gobject-introspection/-/commits/master Jun 17 10:05:04 kanavin_home: nice :) Jun 17 10:07:30 kanavin_home: indeed! Thank you :) Jun 17 10:15:37 kanavin_home: I assume you'll send a backport and I should wait for that before the next test build (and include it in M1)? Jun 17 10:16:21 RP: sending right now Jun 17 10:16:38 RP: sent Jun 17 10:18:06 kanavin_home: thanks! Jun 17 10:20:53 kanavin_home: btw, I think dhcp is holding the bind versions and looks to have segfault issues too. I talked a bit with armpit about that yesterday, it gets complicated :( Jun 17 10:21:06 we may want to split dhcp to use its own bind Jun 17 10:30:43 RP: did you consider replacing the original dhcp with kea? https://www.isc.org/kea/ Jun 17 10:50:07 kanavin_home: armpit was saying that would happen sooner or later but its not stable yet? Jun 17 11:33:13 RP: if you scroll down that page, they mark 1.6.2 kea as 'stable' Jun 17 12:24:59 kanavin_home: might be time to switch if that is the upstream direction... Jun 17 13:30:35 does somebody know a good reference (blog, tutorial, etc) for building a library with cmake? Jun 17 13:39:27 I just added the meta-openembedded layer from git://github.com/openembedded/meta-openembedded.git and the openembedded-core from git://github.com/openembedded/openembedded-core.git and when I do bitbake-layers show-layers it gives me this error: Jun 17 13:39:31 NOTE: Starting bitbake server...Traceback (most recent call last): File "/opt/graylog-poky/bitbake/bin/bitbake-layers", line 93, in ret = main() File "/opt/graylog-poky/bitbake/bin/bitbake-layers", line 61, in main tinfoil.prepare(True) File "/opt/graylog-poky/bitbake/lib/bb/tinfoil.py", line 408, in prepare Jun 17 13:39:32 self.run_command('parseConfiguration') File "/opt/graylog-poky/bitbake/lib/bb/tinfoil.py", line 466, in run_command raise TinfoilCommandFailed(result[1])bb.tinfoil.TinfoilCommandFailed: Traceback (most recent call last): File "/opt/graylog-poky/bitbake/lib/bb/command.py", line 74, in runCommand result = command_method(self, commandline) Jun 17 13:39:32 File "/opt/graylog-poky/bitbake/lib/bb/command.py", line 275, in parseConfiguration command.cooker.parseConfiguration() File "/opt/graylog-poky/bitbake/lib/bb/cooker.py", line 437, in parseConfiguration self.handleCollections(self.data.getVar("BBFILE_COLLECTIONS")) File "/opt/graylog-poky/bitbake/lib/bb/cooker.py", line 1229, in Jun 17 13:39:33 handleCollections raise CollectionError("Errors during parsing layer configuration")bb.cooker.CollectionError: Errors during parsing layer configuration Jun 17 13:39:49 Has anyone seen this before? Jun 17 13:40:11 I have switched an x86-64 target away from multilib, and I'm having a ld.so issue: an externally-built binary wants to use /lib64/ld-linux-x86-64.so.2 which is not there, and on exec gets ENOENT. Could be normal, and indeed calling ldso explicitly goes a bit further, except that 1. ldd reports "/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2", and 2. adding a /lib64/ld-linux-x86-64.so.2 symlink (as is the case on my Debian host) does Jun 17 13:40:11 not change the ldd output. Any idea what lies behind ? Jun 17 13:41:33 chris_ber: if I may allow a suggestion, better go meson if possible - among other things their doc is much better Jun 17 13:43:37 (but it the question is about packaging, "inherit cmake" is usually sufficient) Jun 17 13:43:38 yann: meson has other drawbacks if you ask me, but actually the only thing that really matters is that one uses a build system, instead of hand-carved Makefiles. Jun 17 13:45:32 Letothe2nd: for what I've seen for building a project with complex rules (for which I had a complex hand-carved Makefile initially), I found meson vastly superior to cmake, and the meson community much more responsive when hitting a limitation (still waiting for an answer from cmake side after severl months - in fact not waiting any more ;) ) Jun 17 13:46:11 as far as i'm concerned, cmake is in the past now Jun 17 13:48:23 yann: :) no objection from my side. use wahtever suits your needs and workflows best. just no hand carved makefiles :) Jun 17 13:49:28 Letothe2nd: why? :D Jun 17 13:49:46 * yann still regrets that his make-fu will become useless :D Jun 17 13:49:46 * Letothe2nd slaps qschulz with a large trout! Jun 17 13:50:20 yann, without multilib enabled (you don't have to use multilibs) the libdir goes to 'lib' and not lib64. Jun 17 13:50:55 so if you care about external binaries that conform to the ABI specs/LSB ABI specs.. then your only option is to enable multilibs, but not actually use multilibs -- just the base configurations Jun 17 13:52:06 (when I was at Wind River this is what we did.. ABI conformance was a big deal for us, so we always enabled the multilib configs to ensure the lib dirs were set the way we wanted, but only a few instances we actually compiled multilib userspaces.) Jun 17 13:52:16 I still don't understand much why it does not load, while obviously someone has taken care of ABI compatibility with this "/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2" translation Jun 17 13:54:58 I have to re-enable multilib someday anyway, if only to followup the bugreport of mine for which it started breaking on me (and which triggered my tentative switch away from it), but I'd like to understand what's going on here Jun 17 13:56:11 Srijan: use pastebin please, your error is uneadable in the chan Jun 17 14:04:01 yann: here it is. https://pastebin.com/ZsxD5R7a Jun 17 14:05:14 Srijan: syntax error in bblayers.conf ? Jun 17 14:05:46 missing trailing backslash maybe ? Jun 17 14:06:29 No i checked that and then did some google search and came across this https://stackoverflow.com/questions/59127987/bitbake-layers-add-layer-meta-python-meta-raspberrypi-failed....it has resolved my issue temporarily Jun 17 14:38:28 Does somebody have an idea why if got this message by adding a cmake-base repo (with devtool add ...): `#NOTE: the following library dependencies are unknown, ignoring: libprom` although i have such a recipe and i added it with `IMAGE_INSTALL_append = " libprom"` in local.conf Jun 17 14:41:16 chris_ber: did you add it to DEPENDS where applicable ? Jun 17 14:41:38 chris_ber: if you DEPEND on something, don't add it to IMAGE_INSTALL Jun 17 14:41:39 you should not use IMAGE_INSTALL_append for this Jun 17 14:42:20 * yann concedes victory on this to Letothe2nd :) Jun 17 14:42:44 \m/ Jun 17 14:57:19 i am confused: where/how should i add the library? Jun 17 14:59:58 chris_ber: if it's a build time dependency of your new recipe. in DEPENDS of your said recipe. If a runtime dependency of said recipe, in RDEPENDS_${PN} of said recipe. If "final" package (i.e. nothing that depends on it is installed in the image) then IMAGE_INSTALL or alike in your image recipe Jun 17 15:00:22 qschulz: perfect answer. Jun 17 15:00:59 guess i should do a session on that in some form. Jun 17 15:06:29 ok, but i thought when i use a cmake-based repo, the generated recipe will automatically include this by extracting it from 'target_link_libraries...'. The recipe-build says explicit it can't find the lib/package but the lib is in sysroot. Sure i can add 'DEPENDS' by myself, but this does not seems right Jun 17 15:06:39 I'd add, usually no need to add it th RDEPENDS_${PN} if it is in DEPENDS, the former will be auto-filled if the lib is linked to your program/lib Jun 17 15:07:02 it has to be in sysroot, that's what DEPENDS is for Jun 17 15:08:43 chris_ber: cmake won't magically know which recipes to add to DEPENDS (which will bring headers, libraries, etc.. to recipe-sysroot(-native)), so you need it anyway. Jun 17 15:08:49 yann: i got this message in my application when i try to use my own library: '# NOTE: the following library dependencies are unknown, ignoring: libprom' Jun 17 15:09:31 qschulz: i am not sure because the note said it at least try to find it Jun 17 15:09:39 tried Jun 17 15:10:14 chris_ber: you probably confused the image to flash on the target (which you modified with IMAGE_INSTALL_append) and the (per-recipe in recent yocto versions) sysroot used for the build Jun 17 15:10:26 chris_ber: well... I can look for you in my office space. Will you be here if I don't ask you to be here :) ? Jun 17 15:11:49 chris_ber: if the library is available in the sysroot of your new recipe, then something needs to be fixed. If it's not there, cmake will still look for it obviously but won't find it, so you need to put the library in the sysroot, which is done by using DEPENDS in your new recipe Jun 17 15:13:17 but maybe I didn't correctly understand your question? Jun 17 15:14:02 maybe i am not good in explaining ;) Jun 17 15:18:12 1. i build a library "libprom" 2. i added this library with "IMAGE_INSTALL_append = " libprom" (you guys saing this seems is wrong??) 3a. i add with "devtool add --srcrev git_to_my_app" 3b. In the CMakeLuists.txt i use ''find_library(... libprom.so ... ) and target_link_library" Jun 17 15:18:44 i should maybe use bitbin Jun 17 15:19:10 chris_ber: you should but I think it's fine for now :) Jun 17 15:19:34 chris_ber: I think yann found what your problem is Jun 17 15:20:32 IMAGE_INSTALL is for an **image** recipe (so that the package you added in IMAGE_INSTALL makes it to the rootfs). Anything done there can *not* be used in other recipes because recipe data is local. Jun 17 15:21:10 so... if you want your recipe to be able to find headers, libraries, etc... from another recipe in your recipe, you need to add it to DEPENDS Jun 17 15:21:11 further more, the image is built *after* all individual packages are built Jun 17 15:25:35 ok, thx. i understand the issue with the image. But how to make other recipes know that my libprom exists? 'DEPENDS' is for recipes tha uses other dependencies. I mean the recipe-builder tries to find a package/lib Jun 17 15:26:52 recipe A needs libprom at build time right? Jun 17 15:27:25 so i think there should be an option in the libprom-recipe where i can tell: here is a lib that can use by other parties Jun 17 15:27:57 chris_ber: that's done for you by Yocto defaults in 99% of the cases Jun 17 15:28:16 i think only the headers, the libprom is shared library Jun 17 15:28:54 that's done for you by Yocto defaults in 99% of the cases <- than i don't understand why the recipe-builder can't find it Jun 17 15:29:16 (and that "option" is called SYSROOT_DESTDIR) Jun 17 15:29:31 ok Jun 17 15:29:42 or SYSROOT_DIRS I never know exactly Jun 17 15:29:49 and no, /usr/lib is in it Jun 17 15:31:07 so... 1) is your lib in recipe A recipe-sysroot directory? a) no => is your libprom recipe in DEPENDS of recipe A? i) yes? then what's the path to your libprom.so in your libprom package? Jun 17 15:31:41 ii) no? add it :) and start back to 1) if there is still an issue Jun 17 15:32:28 b) yes? then probably cmake does not look at the proper place for your lib, so you might need to add the correct path to LDFLAGS in your recipe A or something along those lines Jun 17 15:32:35 but let's start with 1) :) Jun 17 15:35:15 ok, just to know what we are talking about https://bitbin.it/onFlnMJx/ Jun 17 15:37:57 1) No it isn't in recipe-sysroot. Jun 17 15:38:24 chris_ber: ok so you're complaining that devtool couldn't automagically find your DEPENDS on libprom actually :) Jun 17 15:38:46 yes Jun 17 15:39:43 adding manually 'DEPENDS += " libprom" --> it is in recipe-sysroot Jun 17 15:39:54 so, to fix your problem you need DEPENDS on libprom but I think you've understood now :) I don't know exactly how devtool is finding which recipes to add to DEPENDS Jun 17 15:40:45 chris_ber: the output of devtool add is usually just a blueprint for a recipe, you'll mnost likely need changes in the recipe anyway. Jun 17 15:42:00 I barely use devtool so I cna't say if it's a bug within devtool, if you forgot to do something before doing the devtool add (have you built libprom with bitbake for the same machine for example?) or if you're missing something in your libprom recipe Jun 17 15:42:03 i tried to put more output in 'recipetool/create.py' or even tried to set breakpoints with pdb, but this fails. Using the option '-d' failed too Jun 17 15:43:14 qschulz: i tanhk you for your effort. i have 2 books, but not these, manuals or anything else helped me. I try to avoid to do to much manually Jun 17 15:43:19 thank Jun 17 17:27:33 Does the sorting of layers in the variable "BBLAYERS" play a role? Where exactly can I read about the priorities of the layer and the BBLAYERS variable? Jun 17 17:32:12 silviof: it does. For example for the order in which layers are parsed to find the first occurence of a bbclass (the layer priority isn't taken into account for bbclasses, just the order within BBPATH) Jun 17 17:32:52 silviof: the order matters for layers with the same priority to know which bbappend to apply first or if two recipes with the same name and version, which will be taken Jun 17 17:34:57 silviof: to be fair... your layer and your build behavior/result should not care about the order in which layers are included, or care but as few as possible. It's a dangerous road to roam if you need to maintain layer priorities and bblayers order in order to be able to build your image. What happens when you need a similarly "broken" layer and it needs to be both after and before another layer? Jun 17 17:56:12 kanavin_home, kea is currently in meta-oe Jun 17 17:56:39 maybe time to move it along with moving bind forward Jun 17 18:14:32 * silviof sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/VAvMdfcvgrVqYcvMOvJfZXMP > Jun 17 18:16:49 By mistake I wrote BBPATH, but I meant BBLAYERS Jun 17 18:25:01 silviof: I guess Matrix wrapped your message there. It's not helpful though as the user you tagged isn't going to receive any notice if they're not tagged in the actual IRC message Jun 17 18:29:00 paulbarker: Thanks for hitting me. See the result in http://logs.nslu2-linux.org/livelogs/yocto.txt . thanks. Jun 17 18:30:26 qschulz Thanks for the explanation.Until now I have never cared about the BBLAYERS variable.Today, however, I have learned that this is very important. I have in meta-openembedded (layer-1) a recipe A with version 1.0. I have created 2 layers in one (layer-2) I have a recipe with version 2.0 and in the third layer (layer-3) I overwrite Jun 17 18:30:26 configuration files for the recipe in layer-2. So bbLAYERS="layer-2 layer-3 layer-1" Now I notice that layer-1 is overwriting the configuration file, and possibly other files. Is there anything I can do to avoid having to re-sort my layers now? Jun 17 19:13:52 silvio2: i'd try and find an approach that does not rely on the order Jun 17 19:14:45 silvio2: some things to look into are machine/distro dependent appends, for example Jun 17 19:16:24 @Letothe2nd That's why I'm asking my questions here. I can't come up with a specific solution. Jun 17 19:17:06 ... the hope was that there was a general solution for this. Jun 17 19:19:49 silvio2: the general point is that if your layer needs a specific ordering, it has to be considered buggy Jun 17 19:20:51 silvio2: the solution might need to include changing recipe names, refactoring into includes, all kinds of stuff. hard to give proper advice without seeing the real specific thing Jun 17 19:26:17 @Letothe2nd Oh, that's easy - rename the recipe and you're done. If that's the solution, I'll take it. I just didn't think that was a real option. Jun 17 19:27:40 silvio2: if you control the layers and what consumes them, about everything is viable option. Jun 17 19:55:34 hum, where is the distro compatibility listed? dunfell fails me on debian buster, and i'm wonderein Jun 17 20:09:18 Letothe2nd, see SANITY_TESTED_DISTROS in ./meta-poky/conf/distro/poky.conf Jun 17 20:21:45 some fun with qemu-system-native, it seems. ASSUME_PROVIDED to the rescue? or what? Jun 17 20:30:02 strange, now it works. Jun 17 20:32:35 Why do vendor BSP's suck SO BAD!!!!!!! Jun 17 20:33:28 I'm going to make meta-vendor-shit-that-just-works Jun 17 20:40:59 Crofton|cloud: Which one has irked you today? Or is it just collectively all of them? Jun 17 21:41:41 hi Jun 17 21:44:41 what exactly happens during the booting of a yocto generated linux image? is u-boot the first piece of binary that is run ? Jun 17 21:45:39 :/ Jun 17 22:27:18 * armpit curse you bind... Jun 17 23:58:10 armpit: DNS or the syscall? Jun 18 00:01:57 mranostay: heh, going by the mailing list discussions, the former Jun 18 01:46:01 Crofton|cloud: meta-vending-machine Jun 18 01:46:25 heh Jun 18 01:55:58 How to integrate bootgen utility building in yocto? Jun 18 01:56:21 DESCRIPTION = "Bootgen application - Xilinx to create boot.bin" Jun 18 01:56:39 I get the error - g++: error: unrecognized command line option ‘-fmacro-prefix-map=/home/xxx/temp/custom_yocto/build-custom-zynq/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/bootgen/git-r0=/usr/src/debug/bootgen/git-r0’ Jun 18 01:56:39 ‘-fmacro-prefix-map=/home/xxx/temp/custom_yocto/build-custom-zynq/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/bootgen/git-r0=/usr/src/debug/bootgen/git-r0’ Jun 18 01:56:40 ‘-fmacro-prefix-map=/home/xxx/temp/custom_yocto/build-custom-zynq/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/bootgen/git-r0=/usr/src/debug/bootgen/git-r0’ Jun 18 01:56:40 ‘-fmacro-prefix-map=/home/xxx/temp/custom_yocto/build-custom-zynq/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/bootgen/git-r0=/usr/src/debug/bootgen/git-r0’ Jun 18 01:56:42 'imageheadertable-versal.o' failed Jun 18 02:11:53 shrey: I would check where that command is coming from Jun 18 02:12:33 shrey: and you might be using the HOST compiler which might be old or something **** ENDING LOGGING AT Thu Jun 18 02:59:57 2020