**** BEGIN LOGGING AT Sun Apr 12 03:00:14 2020 Apr 12 07:25:00 New news from stackoverflow: How to use the latest oe-depends-dot in Yocto Apr 12 17:41:46 sup world Apr 12 17:42:57 wazzuuuuuppp Apr 12 17:43:33 i noticed yocto makes the images with busybox is there any way to bring in a bash ver of a app ie "date"? Apr 12 17:43:43 sup nameclash Apr 12 17:44:26 lots of time on my hands do to cv-19 Apr 12 17:45:04 add the corresponding package to your image (e.g. core-image-minimal.bbappend) Apr 12 17:45:28 Yocto_newb: The "bash" version is usually from the coreutils package, which does exist in Yocto, you just have to include it in your image. Apr 12 17:46:13 well "date" is on the image but it is using busybox ver of "date". Apr 12 17:46:32 Yocto_newb: Yes, you need to install coreutils for its version of date. Apr 12 17:46:34 IMAGE_INSTALL += " coreutils" Apr 12 17:46:43 The update-alternative mechanism should automatically prefer the coreutils version. Apr 12 17:46:43 so you saying if i bitbake date it will compile the bash ver? Apr 12 17:47:05 There's no such thing as the "bash" version, bash is a shell, coreutils a completely separate package of small utility binaries. Apr 12 17:47:20 And you can't "bitbake date", you need to add the coreutils package to your image using IMAGE_INSTALL. Apr 12 17:47:34 sweet thank you so much Apr 12 17:47:42 it should update the alternatives to point to the coreutils version instead of the busybox one Apr 12 17:50:01 thank you! thank you ! i dont know why yocto hasnt gotten better faq's and these mailing lists are a nightmare Apr 12 17:51:09 It's a powerful system, but it comes with quite a bit of complexity. Unfortunately, I don't think there's a good alternative other than putting your own share of debugging time into it to understand how it works. Apr 12 17:51:20 The documentation isn't bad, though, if you know what to look for. Apr 12 17:54:08 ive been workin round the clock for last 4-5months or so.. ive started to understand most of the basics got most of my software functional now just finishing touchs and tweeks Apr 12 17:56:06 i seen some of the postinstall stuff using run-postinstalls? is there an advantage to using yoctos way vs just making a start up script? Apr 12 17:57:04 does it run the postinstall before making the image? vs startup script runs at first boot? Apr 12 18:02:49 this chat reminds me of my aol warez days.... sitting in a room with 200+ bots and no people? Apr 12 18:06:21 Lots of people do Yocto at their day job and are currently on holidays. Apr 12 18:06:29 That doesn't mean their IRC clients aren't running, though. Apr 12 18:08:34 aye, it's usually quiet outside work hours, but it being easter for a lot of folks makes it even quieter Apr 12 18:09:00 irc is generally pretty asynchronous. ask your question, wait for a response whenever someone comes back Apr 12 18:53:58 stupid question? the idea of using the local.conf for settings is like debugging right. everything in local.conf should be moved into pacakagegroups and image file based on core image for deployment?right? Apr 12 18:59:27 stupid question? the idea of using the local.conf for settings is like debugging right. everything in local.conf should be moved into pacakagegroups and image file based on core image for deployment?right? Apr 12 19:00:06 or distro, or machien, or wherever it's most appropriate, yes Apr 12 19:00:20 there are those that version control local.conf, but it's a mistake to do so, best to keep it for local build settings, testing, debugging Apr 12 19:01:24 making your own layer and distro and image recipes is pretty easy and highly recommended. there's a sort of mental barrier, folks think it's harder than it is :) Apr 12 19:01:33 so is every setting in local.conf is able to be set elsewhere Apr 12 19:02:10 not everything. DISTRO/MACHINE have to be set there or earlier, as conf/machine/${MACHINE}.conf and conf/distro/${DISTRO}.conf are parsed after local.conf Apr 12 19:02:23 but most things Apr 12 19:02:38 ya i made a layer just switching off of local.conf within the last week Apr 12 19:09:43 so i havent found much documentation about rdepend depend and install_image is seems things dont always install if not put under the right var. i know rdepend and depend in a recipe is the difference between runtime and compile. and some things that have been installed with install_image can be moved to depends but not the other way around? what im Apr 12 19:09:44 i missing? Apr 12 19:12:19 bitbake only builds what's needed, and it all starts with what you specify on the bitbake commandline Apr 12 19:12:38 'bitbake someimage' will build the someimage image recipe and what it depends on and nothing else Apr 12 19:13:10 IMAGE_INSTALL specifies what packages are installed into that image. anything else comes indirectly by what those packages rdepend on, or the recipes that emit those packages depend on Apr 12 19:14:26 if IMAGE_INSTALL references a packagegroup, then you could include an additional package either via IMAGE_INSTALL directly or via the rdepends of that packagegroup, or anything it depends on Apr 12 19:15:24 depends isn't going to put anything into an image directly, ever. it only affects what gets built. if a recipe DEPENDS on something and then links against a library from it, oe's automatic shared library detection will add the rdepends implicitly, but otherwise it won't affect the image contents at all Apr 12 19:16:00 sweet Apr 12 19:16:28 thank you that clears up a lot Apr 12 19:16:43 no problem. i could go into more detail, but that's probably all you want to know Apr 12 19:16:44 :) Apr 12 19:18:36 so something installed under image_install could be removed and switched to rdepends? or would switching it to rdepends loose packages Apr 12 19:19:02 well that depends on what recipe's rdepends you're adding it to and whether that recipe's package is already in IMAGE_INSTALL Apr 12 19:19:17 ex. you could move from IMAGE_INSTALL to a packagegroup's RDEPENDS if that packagegroup is already in IMAGE_INSTALL or is otherwise pulled in Apr 12 19:19:30 otherwise you'll just end up with a package with a dependency sitting in tmp/deploy/ but not actually used for anything Apr 12 19:19:34 ok Apr 12 19:19:53 thats what i was missing Apr 12 19:20:30 i didnt think about the packagegroup being listed under install_image Apr 12 19:20:32 like i said, it'll only build the targets you speciyf on the commandline and what they depend on, if you add it to something that isn't already being pulled in, it won't do much unless you explicitly build those targets Apr 12 19:20:57 we have thousands of recipes, so it won't go off and build what it doesn't have to :) Apr 12 19:21:09 same for the image, we don't want packages installed bloating the image unless they're actually needed Apr 12 19:21:48 sweet thank you so much for taking time to help me Apr 12 19:22:06 but consider the purpose of things. if the packagegroup in question makes sense to always pull in a given package given its purpose and scope, by all means mov eit, but if it's really only useful in this one image, it might be best left in IMAGE_INSTALL Apr 12 19:24:06 Yocto_newb: on a related note, especially with regard to what goes where, i'd suggest reading https://gist.github.com/kergoth/d2d4f7ed65561e67ef09f258ba73111d — it's slightly out of date, and isn't written the best, but it still covers a key principle Apr 12 19:24:55 sweet Apr 12 19:26:51 do you maintain your own layer somewhere? Apr 12 19:27:59 Not one specific one. I work for one of the Yocto member companies as an operating system vendor (Mentor Graphics), so much of my work on yocto & oe is done for them, in their layers. I do have a variety of personal ones, but they're mostly for specific purposes and personal use, proof of concept of features before i submit them, or old prototypes that weren't viable, etc Apr 12 19:28:24 I maintain meta-external-toolchain, meta-sourcery, and meta-mentor most visibly. Apr 12 19:28:54 wow very impressive!!! Apr 12 19:29:07 I was one of the founders of bitbake & oe back in the day, but am not nearly as involved as in the past, Richard is a way better maintainer than I ever was :) Apr 12 19:29:21 WOW Apr 12 19:29:30 a bit hard to believe it's 16 years old now. now i feel old Apr 12 19:30:09 isnt openwrt and ddwrt based on yocto too? Apr 12 19:30:54 last i checked openwrt was buildroot-based, but i admittedly havent' checked it out in ages Apr 12 19:31:34 ya i know the old feeling i still remember aol1.0 on a floppy you had to copy it to dos to run it... Apr 12 19:32:36 a big part of why oe exists is a number of us outgrew buildroot, it wasn't scaling to what we needed for long term distro maintainence. which is a big difference between the two. buildroot and its variants are fantastic for quick stuff, board bringup, etc, but isn't as great for the longer term. yocto/oe is great for the longer term but has a bigger learning curve. so it's a tradeoff. Apr 12 19:34:15 i dont know never used buildroot .. yocto is my first attempt to make a distro Apr 12 19:34:38 its been a rather fun journey Apr 12 19:35:48 That makes sense, building a linux distro is interesting indeed, i imagine that's the attraction of projects like linuxfromscratch as well. there's something to seeing how the pieces of a linux system fit together Apr 12 19:35:49 is there an advantage to using yoctos postinstall vs making a startup script? Apr 12 19:36:26 postinstall usually just runs once on first boot, and even then only if it's explicitly marked as not being able to be done at image creation time, otherwise that's when it'll be run Apr 12 19:37:02 so no difference really then? Apr 12 19:37:34 not really, again comes down to the purpose and where it makes the most sense conceptually, but many could be done either way. Apr 12 19:37:56 one way to consider it is to think about the use case of installing the packages at runtime on target. what would be the behavior then? you might not care, but it helps to clarify Apr 12 19:38:10 since a postinst would run at package install time in such a case Apr 12 19:38:21 ex apt-get update; apt-get install foobar Apr 12 19:39:14 so postinst runs within yocto not on first-boot? Apr 12 19:39:35 when the image is built, yeah, unless it's marked as being only able to be run on target Apr 12 19:39:49 since that's when the package is installed into the rootfs, at image build time Apr 12 19:40:41 oh wow that makes a big difference i thought postinstall ran on targets first boot Apr 12 19:49:23 kergoth: as you mentioned people being of.. .just for the record, i'm pretty much out of the loop until mid of may Apr 12 19:50:13 thank you so much for you time kergoth **** ENDING LOGGING AT Mon Apr 13 02:59:57 2020