**** BEGIN LOGGING AT Tue Jun 09 02:59:57 2020 Jun 09 04:52:16 what is the name for the variable suffix in cases like PREFERRED_VERSION_ or RDEPENDS_? it seems like it could be "variable override," but that seems maybe inaccurate Jun 09 04:56:10 (it does seem like maybe they are separate cases with the latter being an override and the former being some kind of package specifier ... but it'd be nice to know where that vocabulary is described to make cross-referencing it against the documentation easier) Jun 09 08:12:56 Hi, i have a question and i couldn't find an answer so here i am now: is it possible to declare a dependency in that way that whenever i build recipe 'A' recipe 'B' should also be rebuild. independent if the source of 'B' changed? Jun 09 08:14:11 fneddy: i think a DEPENDS should already do that trick Jun 09 08:18:28 ok, then i have done something wrong in my recipe, till try to debug. good to know that i am on the right way through :) Jun 09 08:19:17 fneddy: what is the *actual* problem, though? because this sounds very much like a x-y situation. Jun 09 08:20:37 we have a recipe B that generates some files that are used in A. But we cannot use an *old* result of B. so whenever A rebuild B should also rebuild. Jun 09 08:21:40 that is just rewording, plus describing the dependency backwards. Jun 09 08:27:59 Mmmm just wondering if there is a way to create a dot file to find which recipes are dependent on a specific recipe and ideally in a tree fashion Jun 09 08:28:30 fneddy: or wait. A uses the files of B. so you really want B(!!) to rebuild if A rebuilds? so, if the *consumer* is being rebuilt you also want the producer to follow? Jun 09 08:28:43 I could grep the dot file but then I lose the information of whether it's a direct dependency or not Jun 09 08:30:05 fneddy: because in that case - no, thats not how it works. Jun 09 08:47:37 hmm, will try around. i will come back when i understand the problem better. Jun 09 09:57:04 Hi guys, my bin_package recipe complains about libXdamage.so.1 and a whole lot of libXblahblah missing Jun 09 09:57:26 But I made my recipe DEPEND on it, what am I doing wrong? Jun 09 09:57:42 kriive: you are using a bin_package. Jun 09 09:58:40 Yeah ahahah indeed Jun 09 09:59:38 But that's my only option, employer said: we must use this specific version of teamviewer (which is only available in an ancient .deb downloaded from Ubuntu years ago) before we can actually consider using you fancy solution based on Yocto Jun 09 10:00:14 hello, who has informations about kernel menuconfig of the yocto project ? Jun 09 10:00:32 bitbake -c menuconfig virtual/kernel Jun 09 10:01:31 gaston53: what's the actual question? Jun 09 10:01:50 kriive: i have to admit unless i can actually bill your employer for it, i do not feel inclined to give more advice than "look at the bin_package class to see what it does, look at the error logs, have fun wasting your time with it." Jun 09 10:01:52 kriive: you're probably missing a lot of RDEPENDS aren't you/ Jun 09 10:02:27 qschulz: as he didn't even say when or when doing hat that error occurred? ;-) Jun 09 10:03:29 kriive: DEPENDS and bin_package do not make sense at all Jun 09 10:03:57 DEPENDS is for build time, but you're not "building" the source code because well... it's already pre-compiled for you Jun 09 10:04:45 qschulz: unless the bin_package in question has fun with pre-postinstall scripts.... Jun 09 10:05:01 * Letothe2nd is being the grumpy Jester :) Jun 09 10:05:16 qschulz menuconfig is used to add or remove some features. For example, I want to remove SPI support from my kernel. When I look for SPI in device drivers ( in the menuconfig ) and hit `shift+?` to see informations about this SPI, a window appears with some informations Jun 09 10:05:22 like Jun 09 10:05:30 depends on : .... Jun 09 10:05:36 selected by : ... Jun 09 10:05:43 selects : ... Jun 09 10:06:13 should I remove the SPI without taking care about those ? Jun 09 10:06:24 and rebuild my image Jun 09 10:07:30 gaston53: "should I not take care of dependencies?" well.. :) Jun 09 10:08:15 That's my question, one of the error says: nothing provides libXdamage.so.1 needed by teamviewer-12.1.83885. But my RDEPENDS has explicitly libxdamage in it, that's what confuses me Jun 09 10:08:50 qschulz dependencies will be carried automaticaly when I rebuild the kernel ? Jun 09 10:09:01 that's the use of the menuconfig Jun 09 10:09:04 right ? Jun 09 10:09:11 gaston53: yes but not exactly Jun 09 10:09:22 Letothe2nd: yes, but that prepostinstall will come later, I haven't managed to reach that point yet Jun 09 10:09:43 gaston53: rule 1: do not edit defconfig by hand but it seems you're already following this one Jun 09 10:09:51 kriive: billing address? Jun 09 10:10:06 the issue with using menuconfig only is that it does not save the changes in a defconfig. Only in the local .config Jun 09 10:10:42 qschulz I have tried to do it by hand but when I rebuild the kernel I must select each time if I want to add X or to add Y feature Jun 09 10:10:46 gaston53: so when your recipe is rebuilt, depending on which task has to be done again, it'll erase your changes Jun 09 10:11:04 Letothe2nd: Gotta pay university bills man sorry, I will try something else haha Jun 09 10:11:10 gaston53: there is a reason menuconfig exists, so do not edit by hand :) Jun 09 10:11:22 kriive: have fun then! Jun 09 10:11:48 gaston53: so.. once you've saved your config with menuconfig, you probably need to run savedefconfig as well Jun 09 10:11:49 yeah Jun 09 10:12:17 then with this defconfig (available in WORKDIR/build of your recipe IIRC), add it to your recipe or patch the original defconfig you used Jun 09 10:13:08 that's the very basic workflow, but Yocto provides support for kernel defconfig fragment (.scc of .cfg files) so you can also do diffconfig I think and just add this fragment to your recipe. This is supported if kernel-yocto is inherited by your recipe Jun 09 10:13:27 Which isn't the case for all BSPs, so you have to check Jun 09 10:14:11 qschulz yes I read about this Jun 09 10:14:26 qschulz let's go back to my first questions Jun 09 10:14:43 If I remove, for example, SPI Jun 09 10:15:01 the " selects " feature will be removed also Jun 09 10:15:18 if they are not used by something else Jun 09 10:15:22 right ? Jun 09 10:15:26 gaston53: not necessarily, if something else depends on it or selects it, it'll stay Jun 09 10:15:36 yes Jun 09 10:15:53 besides Jun 09 10:16:12 " depends on " Jun 09 10:16:20 kriive: I suspect libdamage package is providing libXdamage.so.1.X and not libXdamage.so.1 which should be a symlink Jun 09 10:16:32 if I chose to put SPI again Jun 09 10:16:36 gaston53: or if explicitely enabled Jun 09 10:16:55 should I select " depends on " manualy in the menuconfig Jun 09 10:17:02 or will be selected automaticaly Jun 09 10:17:03 ? Jun 09 10:17:31 gaston53: mmmm actually I think I'm wrong. If you have selected a Kconfig entry which does a "selects" I think it does not un-select them. Anyway, that's a topic more for some other IRC channel :) Jun 09 10:18:12 gaston53: yes, depends on needs to be satisfied before you can enable the Kconfig option which has the "depends on" Jun 09 10:19:01 if they are enabled autmaticaly it will be better :/ Jun 09 10:19:04 (you should have seen that you can't even select and see the option (except in the search) if the depends on is not satisfied Jun 09 10:19:50 gaston53: you can't, because it's a reverse dependency and some are architecture dependent Jun 09 10:20:20 so how do you know which one to enable? (some Kconfig options have a depends on THIS && THAT || THOSE Jun 09 10:21:03 gaston53: but just to be clear, that's nothing to do with Yocto (menuconfig and Kconfig mechanism) Jun 09 10:21:57 qschulz I was about asking last question but you made me stop :p Jun 09 10:22:06 so where can I ask about this ? Jun 09 10:23:18 about what? I answered your question fully I think. What's missing? Jun 09 10:23:44 you said to me that's nothing to do with yocto Jun 09 10:23:53 and I am asking in Yocto room Jun 09 10:24:53 Indeed, but what is missing in your understanding of the Kconfig selection? Jun 09 10:25:11 You should be able to join #linux on freenode. Don't know if it's the proper channel /me shrugs Jun 09 10:25:29 my last question about " selected by " ... for example SPI is selected by ethernet , I remove SPI , but I don't remove ethernet Jun 09 10:25:53 you see ? SPI will be re-enabled if I don't remove ethernet ? Jun 09 10:28:33 My understanding is that selects is just an optional dependency. So if you remove SPI, Ethernet should still be there. No guarantee that it compiles but my understanding is that you can have ethernet without SPI, otherwise you'd have a depends on Jun 09 10:28:41 And tbh, that's something you can test :) Jun 09 10:31:07 gaston53: https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html and I'm out :) We polluted a bit too much #yocto with kernel specific questions :) Good luck! Jun 09 10:32:04 qschulz thanks and sorry for that Jun 09 10:33:08 kriive: so probably needs to patchelf on the original binary to make it depend on the correctly versioned lib or make the package from libdamage to also give libXdamage.so.1 (which should be provided by libdamage-dev but IMO bad idea to add it to your RDEPENDS as it brings a few things you don't need IIRC) Jun 09 11:28:15 qschulz: thank you! I tried adding libXdamage to my RDEPENDS, with no luck haha Jun 09 11:28:46 But I guess I will try to change strategy Jun 09 11:29:23 Maybe using docker + X11 forwarding or stuff like that Jun 09 12:42:38 Okay, running circles in the docs here for something that should be super-easy - how the heck do I run a command *in* the image rootfs? Jun 09 12:43:34 I want to generate a couple of files at the end of the image creation, and I've managed to get most things to work, but it's not inside the root -_- Jun 09 12:45:07 wertigon: Add a function to ROOTFS_POSTPROCESS_COMMAND ? Jun 09 12:50:35 That might be it, thank you! Jun 09 12:51:52 Hmmm, maybe...? Jun 09 12:52:04 No, I do have it in there Jun 09 12:53:13 RP: cheers for the update set - I ran it through AB to make it smooth for you :) Jun 09 12:53:13 what I want to do is to run ldconfig, within the root jail Jun 09 12:53:45 RP: the list of outdated recipes is very short now \0/ the only significant item there is qemu 5.0 update Jun 09 12:53:45 wertigon: and what if the rootfs arch cannot execute on your host? Jun 09 12:54:15 wertigon: that sounds very much like you are actually trying to band-aid something completely different. Jun 09 12:54:20 Letothe2nd: Yeah, that's kinda my problem :P Jun 09 12:54:28 RP: (you can mention that in the status email perhaps) Jun 09 12:54:59 wertigon: try to fix the problem instead of adding band-aid, maybe? Jun 09 12:55:40 Letothe2nd: What I want to do is reduce the boot times by NOT having systemd generate certain files it should have pre-generated to begin with Jun 09 12:56:03 kanavin_home: it was very smooth, thanks. I did notice the builds and the fact it built cleanly! :) Jun 09 12:56:10 more specifically, /etc/ld.so.cache and /etc/udev/hwdb.bin Jun 09 12:56:19 kanavin_home: I was wondering how the list looked now! :) Jun 09 12:56:28 wertigon: hum just do the stuff that gets applied upon image feature read-only-rootfs, then? Jun 09 12:56:31 kanavin_home: you should give the qemu maintainer a good kick to sort that... Jun 09 12:56:56 This can be done by running ldconfig Jun 09 12:57:10 Letothe2nd: I have applied that image feature Jun 09 12:57:27 I have a system cross-build setup starting to work - except for the interesting stuff, the one that needs kernel debuginfo. stap expects to find the kernel debug info somewhere, but vmlinux isn't exported to STAGING_KERNEL_BUILDDIR. If I copy it manually, however, the build does work. Is there any reason not to copy it in kernel.bbclass::do_shared_workdir ? Jun 09 12:57:31 No luck :( Jun 09 12:57:50 s/system/systemtap/ Jun 09 12:58:25 wertigon: those are supposed to be generated at build time. Are you saying they don't get generated or that they're regenerated at first boot? Jun 09 12:58:46 wertigon: we have to consider the cross case which is why ldconfig-native is used for the ld cache, not ldconfig Jun 09 13:00:38 i still there is something weird there, as i have a pretty run of the mill ro rootfs here and the files are around. Jun 09 13:04:01 wertigon: BAD_RECOMMENDATIONS += "eudev-hwdb"? Jun 09 13:04:43 (if it's eudev you're using, which I doubt.. but there might be a similar trick for udev?) Jun 09 13:06:00 RP: Regenerated Jun 09 13:06:39 They are generated but keeps getting regenerated Jun 09 13:06:57 If I look in the overlayfs Jun 09 13:07:20 wertigon: so the question is what is wrong with the files causing them to be regenerated Jun 09 13:07:47 RP: Yes, that or systemd is simply regenerating them out of spite Jun 09 13:08:08 Or rather, as a standard action Jun 09 13:08:36 wertigon: definitely possible, or its seeing timestamps not matching Jun 09 13:08:58 Hmmm, maybe if I copy /etc/udev/hwdb.bin to /lib/udev/hwdb.bin regen Jun 09 13:09:42 I'll try that atleast Jun 09 13:09:53 we can't even bring vmlinux into recipe-sysroot, since it is not exported to sysroot either Jun 09 13:10:33 smurray: did you have a clean way to handle this case ? Jun 09 13:11:03 RP: for qemu I have a WIP patch, which caused lots of red on the AB, so I was hoping the maintainer would get to it... :) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates-later&id=216aea02e5a7fd13f0be368b5bd37ca852b5d3bc Jun 09 13:11:40 kanavin_home: have a link to a failed build? Jun 09 13:11:50 RP: yes, just a sec Jun 09 13:12:17 yann: that was an outstanding issue when I was looking at it, iirc I patched the kernel recipe to deploy vmlinux so it could be used Jun 09 13:13:23 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1037 Jun 09 13:13:38 smurray: ok, I guess sending such a patch in the series will be a good way to start the discussion ;) Jun 09 13:14:26 kanavin_home: interesting, build failures. I can probably debug that... Jun 09 13:19:24 kanavin_home: one thing which puzzles me. I ran 'devtool check-upgrade-status' and it shows me things like "INFO: mc 4.7.5.2 4.8.24 Ross Burton " Jun 09 13:19:35 $ bitbake mc -e | grep ^PV= Jun 09 13:19:35 PV="4.8.24" Jun 09 13:19:50 also no way is mc mine Jun 09 13:20:03 kanavin_home: any idea why it would show 4.7.5.2? Jun 09 13:20:06 rburton: hahaha Jun 09 13:20:24 what, no "MC Ross"? Jun 09 13:20:45 rburton: RECIPE_MAINTAINER_pn-mc = "Ross Burton " Jun 09 13:20:59 RP: clearly thats your baby Jun 09 13:21:31 rburton: I've always been puzzled why you owned it but... Jun 09 13:22:02 RP: if i own it, can i remove it from core Jun 09 13:22:23 rburton: not until I'm on holiday Jun 09 13:22:34 that could take forever Jun 09 13:22:55 rburton: I did say that smiling :) Jun 09 13:25:07 what, there is no metal cover of "dreadlock holiday"? (re: RP on holiday) Jun 09 13:29:06 RP: you have meta-gpl2 enabled Jun 09 13:30:03 somehow devtool picks up the version from there Jun 09 13:34:58 heh, so mc is up for grabs wrt a maintainer? Jun 09 13:35:30 smurray: your chance to become MC Scott! Jun 09 13:38:39 Hi guys, i have a question regarding the yocto builds TMPDIR. We have a project, that builds yocto using docker containers. Now when we mount the yocto TMPDIR via the docker daemon, it takes a long time because of the selinux relabeling of about 7 million files under the tmpdir. Is there a way to reduce the amount of files ? Jun 09 13:39:21 Letothe2nd: heh Jun 09 13:39:49 philipp: i think there is a way to get rid of selinux..... Jun 09 13:39:53 smurray: hi5 Jun 09 13:40:12 philipp: one option would be trying rm_work, that cuts down quite a lot Jun 09 13:40:14 yes it is, but we are using openshift with a special storageclass Jun 09 13:40:19 there is no switch to disable selinux Jun 09 13:41:01 philipp: technically you can use rm_work, but that of course has other drawbacks. Jun 09 13:41:04 philipp: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-rm-work Jun 09 13:41:11 smurray: hi5 again Jun 09 13:42:14 Letothe2nd: would have been faster, but google gives the 1.8 version of the docs pages at the top of results for some reason Jun 09 13:42:30 yeah google loves 1.8, i know. Jun 09 13:42:45 probably they're building some internal stuff on it. Jun 09 13:43:34 thanks guys Jun 09 13:43:39 ill suggest that to our devs Jun 09 13:43:50 suggest getting rid of selinux :) Jun 09 13:44:13 i know, but unfortunately, there is no way to tell openshift not to use selinux for mountpoints Jun 09 13:44:19 its hardcoded Jun 09 13:44:49 its actually hardcoded within the persistent volume driver by vmware Jun 09 13:45:48 philipp: on the other hand, you can use that as marketing material "super duper safe builds" or something along those lines :) Jun 09 13:45:57 :D + Jun 09 13:46:18 it takes docker so long to mount the volume, that the kubernetes api gets a timeout Jun 09 13:46:39 and while selinux relabeling, the whole docker-daemon api gets unresponive, which results in a kubernetes node loss Jun 09 13:46:52 7 million files Jun 09 13:46:57 not too much actually Jun 09 13:47:02 in todays dimensions Jun 09 13:47:15 guess there's a reason why the most of us just use dedicated build hosts :) Jun 09 13:47:34 we had that before, buts its some kind of consolidation project Jun 09 13:47:59 I've got the same issue here, crops up when a relabel gets triggered after a policy update on my build machine Jun 09 13:48:14 whoa even better! "super duper safe and synergy enabled builds!" Jun 09 13:48:25 which isn't usually too frequent, but has happened a couple of times after going to F32 Jun 09 13:48:35 you should consider yourself lucky, being blessed with such an infrastructure :) Jun 09 13:48:52 * Letothe2nd is having a weird day. who could've guessed. Jun 09 13:48:53 philipp: I'm not too familiar with selinux + docker; why is it relabling? Jun 09 13:49:30 basically when you use docker -v hostvolume:containervolume:Z , the :Z will trigger a restorecon -VR on the volume Jun 09 13:49:45 to ensure selinux labels are matching Jun 09 13:49:58 even if its already labeld correctly it takes 2-3 minutes Jun 09 13:50:22 because its looping over all files and directories recursively Jun 09 13:50:25 philipp: Can you bind mount in the working directory instead of using a volume? Jun 09 13:50:41 sure we could, but we want to make use of vmware vsan dynamic volumes Jun 09 13:51:13 what basically happens is, that the kubernetes api will tell the vmware api to gives a new vmware volume, this vmware volume will be attached to the host and then mounted into the docker container Jun 09 13:51:19 Hmm, yeah, moving the hwdb.bin to the lib folder actually worked o_O Jun 09 13:51:36 when resuing that volume for the next build / container, it will check the selinux labels Jun 09 13:51:38 I think atleast Jun 09 13:52:06 ... No, nevermind, it did not. -_-;; Jun 09 13:53:21 i dont even know why the next builds needs the files from the previous build Jun 09 13:53:27 i guess to speed up things Jun 09 13:53:31 i know nothing about yocto^^ Jun 09 13:53:42 philipp: erm no? Jun 09 13:53:56 philipp: the thing worth sharing is sstate-cache, not tmp Jun 09 13:54:08 ah yeah Jun 09 13:54:14 ssstate-cache is already on nfs Jun 09 13:54:15 and shared Jun 09 13:55:15 ah so we can start with a fresh tmpdir for every build? Jun 09 13:55:27 yes, you can Jun 09 13:55:45 and it wont be slower? Jun 09 13:55:57 if you have sstate-cache and dl_dir preserved between runs, it will just pull from sstate-cache what doesn't need to be rebuilt Jun 09 13:56:09 jesus Jun 09 13:56:19 why am i spending hours to fix a problem, that doesnt even exist Jun 09 13:56:19 philipp: marginally, the pulling from sstate takes a little time too, but thats probably negelctable Jun 09 13:56:38 philipp: hum because super duper safe builds?!? Jun 09 13:57:55 great Jun 09 13:57:56 thanks Jun 09 13:58:49 philipp: Ya, "sharing" TMPDIR across different builders isn't viable. It *can* make incremental builds a little faster than sstate if the builds are on the same host, but you'll go crazy if you try to use it across instance :) Jun 09 13:59:08 across hosts is no problem Jun 09 13:59:13 because of the kubernetes dynamic volumes Jun 09 13:59:20 which will automatically be mounted on the correct docker host Jun 09 13:59:32 but ill just tell them to use a new tmpdir volume for each build Jun 09 13:59:43 because everything that can possible be put on NFS, is already on NFS Jun 09 14:00:38 https://twitter.com/TheYoctoJester/status/1270354873188519936 Jun 09 14:00:43 alright, thanks for clarifying things up for me Jun 09 14:10:28 ok our dev says: its neccessary to take the tmpdir into the next stage to minimize build steps Jun 09 14:11:56 philipp: why don't you just send your dev in here? Jun 09 14:12:36 no way Jun 09 14:13:52 so let me recapitulate. "we're suffering because we decided upon this beautiful platform and are totally convinced that our process it the true only one way, so we're not even going to discuss that." Jun 09 14:14:11 sounds like the perfect situation for improvement, i agree :) Jun 09 14:14:40 well the platform is really beautiful for cloud-native container-ready applications Jun 09 14:14:44 haven't followed the whole thing, but if the task hash is different between builds, copying the tmpdir won't change anything as it'll be cleaned anyway Jun 09 14:16:20 philipp: thats all nice and such, but in this case it causes a lot of self-inflicted pain obviously, and the "dev says, won't discuss" is like "why should we care" then, at least for me - and yes i know that sounds arrogant and probably elitist. sorry, at least a little. Jun 09 14:16:36 and if building with copied tmpdir is faster even with sstate-cache enabled, I suspect there is something very wrong going on which is bypassing the sstate-cache or not using it at all for some recipes? it smells either like stinky hacks or the dev does not know what Yocto's doing behind the scenes Jun 09 14:21:40 i dont know, ive told him that there is only one possible solution: do not reuse the tmpdir Jun 09 14:22:41 philipp: I'm late to the conversation but we did design tmpdir to be able to be thrown away "cheaply" Jun 09 14:22:41 im not going to consult him about the consequences of this, because ive never worked with yocto before Jun 09 14:23:27 * Letothe2nd sighs and leaves for good. Jun 09 14:36:03 philipp: Sounds like you're trying to use a sledge hammer to crack a nut. Jun 09 14:36:33 paulbarker: pointless violence FTW! Jun 09 14:53:07 hello, i struggle with a cmake recipe. The recipe is local and i added the recipe myself along with the files. I used `devtool modify myrecipe` to edit the content but i am not able to build because cmake can't find the files although it is working when i call cmake itself: https://bitbin.it/lPf81fK0/ Jun 09 14:54:09 i am new to cmake and i got the feeling the way i added/created the recipe could be wrong Jun 09 14:55:11 YPTM: Jan-Simon is on Jun 09 14:56:01 chris_ber: file://* does not work Jun 09 14:56:07 chris_ber: i don't think SRC_URI does glob. its all just this: do not stuff your sources into the recipe. Jun 09 14:56:31 chris_ber: make it a freestanding repository. (and yes, tahts jsut exactly what i showed you) Jun 09 14:58:41 YPTM: Scott Murray is on Jun 09 14:58:43 chris_ber: using devtool with local files is also debatable. You already have the files so just use bitbake directly. I suspect you might have run devtool modify early when your recipe was wrong and the files haven't been copied (correctly). Until you do devtool reset the devtool'ed recipe will be used by bitbake Jun 09 14:59:47 but as Letothe2nd said, it's strongly advised to use external repositories (such as git, or (versioned) tarballs) Jun 09 15:01:16 qschulz: it also tried file://prom/src/... Jun 09 15:01:44 chris_ber: you're wasting your time on bad, hard to maintainable practises. Jun 09 15:02:39 chris_ber: you can't use * in SRC_URI in any way. So either you add them one by one, or you add one more directory below files which you include (WITHOUT USING *) or you use an external repository (and no, I'm not talking about externalsrc :) ) Jun 09 15:03:19 Letothe2nd: i know, our problem is, that this approach will led to many many rerpositories because we are developing a framwork(packagegroup). I tried to use "devtool modify recipe" and it works fine with local files Jun 09 15:04:04 chris_ber: then use a multirepo. but everything is better than bundling stuff into the layer. Jun 09 15:04:25 YPTM ross joined Jun 09 15:04:31 chris_ber: so you'd rather be bound to a buildsystem rather than handle multiple repos? e.g. if you later decide to move to another buildsystem such as Buildroot, then the whole history is messed up Jun 09 15:04:58 I mean, I am in no way in a good place to critic this as we're doing this (but I hate it) Jun 09 15:05:12 chris_ber: what if, in some distant future, like... in two weeks, decides that using that "framework" without yocto would be cool? like, making a deb package? Jun 09 15:05:13 qschulz: :) Jun 09 15:05:21 qschulz: great minds think alike! Jun 09 15:06:13 chris_ber: "I tried to use "devtool modify recipe" and it works fine with local files" that is confusing to me, what do you mean by that? Jun 09 15:06:22 * Letothe2nd finally calls it a day! Jun 09 15:06:32 are you doing devtool modify and then cmake? you should use devtool build :) Jun 09 15:06:38 Letothe2nd: o/ Jun 09 15:07:25 i discussed with my colleagues about how to handle the framework and the recipes and they like to put in one repo because devtool can handle this with updates. Neverless a lot of books, blogs etc recomend(or at least use local files) Jun 09 15:07:39 so... 1) devtool reset and remove the workspace, 2) use bitbake for building the recipe. Does not work? Send the log and the recipe :) Jun 09 15:08:23 i used devtool modify myr and then devtool build myr Jun 09 15:08:32 i know the procedure with reset etc Jun 09 15:09:14 chris_ber: the files are taken from the devtool workspace, so if you have changed your local files since your devtool modify, that won't update the ones in your workspace Jun 09 15:10:11 qschulz: i didn't modfy any file, because bitbake/devtool struggled with cmake Jun 09 15:10:11 chris_ber: if your workspace files and local files are in sync (please check) and it still does not work, then we'll need the error log Jun 09 15:10:35 ok, give me a sec Jun 09 15:11:10 chris_ber: wild guess (common mistake) you probably aren't using the variables given by Yocto but using hardcoded ones in your cmake files Jun 09 15:11:43 i posted the complete CMakeFile.txt Jun 09 15:12:01 CMakeLists.txt Jun 09 15:13:09 you have others :) Anyway, true, if the error is really the one in the pastebin you sent us, the files haven't probably been installed correctly Jun 09 15:13:27 could you go to the $WORKDIR of the recipe you're trying to build? Jun 09 15:13:47 (tmp/work/// usually) Jun 09 15:14:58 and check that all your files are there? Jun 09 15:15:04 ok Jun 09 15:20:53 qschulz: i reseted the workspace, fixed the licence and run bitbake image again. The files are at the directory you mentioned. The noob-thing is, that it now complains about missing headers. I think you got right and i mixed something with the workspace up. I will know check the includes Jun 09 15:22:00 chris_ber: good, making progress :) Jun 09 15:23:25 in Germany we call this: Von einem Fettnäpfchen zum nächsten. Don't know the translation but i will find the next issue ;) Jun 09 15:24:55 chris_ber: gesundheit Jun 09 15:25:35 but you recommended again we should use external repos. So multirepo is git thing? Jun 09 15:26:58 chris_ber: I haven't got much experience in dealing with that but anyway, you'll need a mechanism to git clone the meta layers that aren't yours (e.g. openembedded-core, poky, meta-openembedded, meta-qt5 whatever) Jun 09 15:27:44 git-repo (an android related project) is used by a lot of people to manage multiple repositories Jun 09 15:28:09 chris_ber: I don't know exactly what Letothe2nd was talking about, maybe git submodules? he also presented kas recently on Twitch so maybe something to have a look at Jun 09 17:03:16 is there a way i can pass a value from the external environment into yocto for use inside of a shell task *without* having that value recorded in any log/run files? it's a secret API token. Jun 09 17:06:40 eden: write it in a file and have it loaded from the file in those scripts? Jun 09 17:57:06 RP: it's already in an env var. is there no way to avoid writing it out? Jun 09 17:57:37 i tried reading out of origenv and asked a question yesterday about it. doing so makes the task metadata hashes not consistent. Jun 09 19:32:31 RP: Is it possible for someone to push https://patches.openembedded.org/patch/172015/ ? Jun 09 19:34:27 We've been using it but hacking it byhand, which is not nice ;-) Jun 09 20:22:23 eden: well it would do unless you exclude it from the taskhash Jun 09 20:22:56 otavio: who is listed as the layer maintainer? Jun 09 20:29:19 RP: Mark Hatle and Jason Wessel Jun 09 20:30:27 fray: can we marge the above patch please? Jun 09 20:30:46 or jwessel? :) Jun 09 20:40:54 hi guys...I'm going through Josef Holzmayr's live series, and got to the part where I'm building a custom kernel Jun 09 20:41:27 and "something" has caused core-image-minimal to grow a whole lot...gnome desktop and everything is getting compiled... Jun 09 20:42:13 any hints on how to figure out where something has obviously gone wrong? Jun 09 20:50:35 the only really blatant copy/paste I have done is that I copied qemux86.conf instead of qeumarm.conf that @Letothe2nd used, and they are quite different, but I can't figure out which setting bloated my image Jun 09 20:51:04 I used https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemux86.conf, where $Letothe2nd used https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemuarm.conf Jun 09 20:58:30 carlsb3rg: you can use bitbake -g to track down where the dependencies are coming Jun 09 21:21:08 trying to browse task-depends.dot...can't say I'm any wiser Jun 09 21:22:00 carlsb3rg: that should do it, if you say gnome is being built you can see where the dependency to build gnome is coming from Jun 09 21:24:08 I can see that gnome-desktop-testing comes from meta/recipes-support...no idea why recipes-support is being cooked tho Jun 09 21:30:04 That is a pretty reasonable patch. I'll see if it can be merged. Jun 09 21:40:00 otavio The patch is merged. Jun 09 21:53:14 finally resolved some licence file issues etc and my wic is 46M...so it seems my actual image is respecting core-minimal-image constraints even though a lot more is getting build Jun 09 23:35:08 jwessel: thanks! Jun 10 00:16:33 Hmm.. I never saw the meta-openssl one.. but if Jason merged, good.. **** ENDING LOGGING AT Wed Jun 10 02:59:57 2020