**** BEGIN LOGGING AT Fri Dec 11 02:59:56 2020 Dec 11 07:38:36 what about updating systemd in dunfell LTS from 244.3 to 244.5? could that be considered, or is systemd stable tree too unstable? Dec 11 07:43:45 good morning Dec 11 07:44:14 good morning Dec 11 07:46:11 yo dudX Dec 11 07:54:30 I'm trying to build core-image-sato on 3.2, but I'm running into an error fetching http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/d/docbook-xml/docbook-xml_4.5.orig.tar.gz. Multiple tries, always "Read error at byte 14600/421525 (Connection reset by peer)." Anyone else or is it something on my end? Dec 11 08:02:47 mmurto: try a manual wget Dec 11 08:06:47 mckoan: Same failure manually Dec 11 08:08:16 Tried on an external vpn and it works, so probably something to do with my network config. Dec 11 08:23:55 mmurto: real life tip: sato is not that useful anyways, so unless you explicitly need it for some specific reason you're almost certainly better off starting with core-image-x11 or even better yet a custom image. Dec 11 08:26:17 LetoThe2nd: Thanks! I'm working on a tool to analyze some aspects of the images, so not really too concerned with the specifics of the images :) Dec 11 08:28:27 mmurto: i see. its just that a lot of beginners think of sato as a good thing to start off as "it is full featured and graphical", and thats certainly not its use case. :) Dec 11 08:30:24 LetoThe2nd: Can't blame them too much, as the quick build documentation uses sato as the example ;) Dec 11 08:31:36 mmurto: does it? Dec 11 08:31:48 qschulz: hey mister documentation, thoughts on this? ;-) Dec 11 08:33:20 LetoThe2nd: Yep, at least here: https://docs.yoctoproject.org/brief-yoctoprojectqs/brief-yoctoprojectqs.html Dec 11 08:33:35 "Start the Build: Continue with the following command to build an OS image for the target, which is core-image-sato in this example" Dec 11 08:35:56 Good point. Maybe we should change that to something more sensible. Dec 11 09:37:47 LetoThe2nd: anything serves as an example. Same goes for poky, it technically shouldn't be used, it's an example distro. Dec 11 09:44:41 I dunno if I remember but was there some .mount file magic going on ? if you included mount files it would automatically add them for systemd mounts Dec 11 09:47:36 qschulz: yeah, but especially sato is misleading IMHO. and it also gets mentioned upon oe-init-env, which isn't helpful either. Dec 11 11:20:21 what's the point of making the difference between a distro and a image recipe? Dec 11 11:23:25 Hey all. I am constantly getting pseudo aborts due to .python-history being created by python Dec 11 11:23:42 wyre: a distro is how you do things, image is what you want. Dec 11 11:23:57 has anybody had the issue? Dec 11 11:23:59 you select your init system in a distro, not in an image Dec 11 11:24:20 there's a very important different between a distro and an image. One is a conf file, the other a recipe Dec 11 11:24:45 and Yocto chant #1 taught us: conf data is global, recipe data is local. Dec 11 11:25:01 which means, you cannot impact other recipes from a recipe, only from a conf file. Dec 11 11:25:38 qschulz, thank you very much for the clarification 😊 Dec 11 11:27:35 wyre: I recommend looking at the poky distro config and then the core-image-base & core-image-full-cmdline recipes to see how it fits together Dec 11 11:27:35 qschulz: https://youtu.be/o-8g0TPVVGg :) Dec 11 11:34:46 wyre: ^ Dec 11 11:39:48 paulbarker, I've been checking the full-cmdline recipe and ... I'm wondering why is not appending to the IMAGE_INSTALL var? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/images/core-image-full-cmdline.bb#n6 Dec 11 11:41:56 could be due it's inheriting form a class instead requiring another recipe? 🤔 Dec 11 12:35:19 wyre: It's most likely that there's just no need to use `_append` here - it's the image recipe so it can set IMAGE_INSTALL directly Dec 11 12:35:46 It's like you don't have to use `SRC_URI_append` in a recipe, you just go ahead and set `SRC_URI` Dec 11 12:36:33 then where you have to use `_append` or `+=` ? (if not in a recipe, I mean) Dec 11 12:36:45 kanavin_home: is there an idiomatic git tag regex for a.b.c to avoid the upstream checker thinking 20201010 is a newer tag than 1.2.3? Dec 11 12:37:49 wyre: _append is when you don't want to append a leading space (technically .= does it too). Dec 11 12:38:13 _append is "resolved" after all += =+ = ?= ??= .= =. are resolved Dec 11 12:38:16 qschulz, I know that, I mean, if I don't need to use append in a image recipe ... where is intended to use? Dec 11 12:39:12 you should use _append in conf files because those are parsed before recipes, so if you use a += and have a default (?=) in a recipe, you actually replace the default instead of appending to it Dec 11 12:39:30 also, if you want to add to a variable only in the case of a machine, you need to use _append_ Dec 11 12:39:32 kanavin_home: no matter, found it Dec 11 12:39:45 because FOO_machine += will replace FOO Dec 11 12:39:52 instead of appending to it Dec 11 12:40:55 I've tried multiconfig to build system controller firmware (different arch). I've added do_compile[mcdepends] and it seems to work. But does it mean I have to prefix all my bitbake commands with mc:main_target: ? Dec 11 12:41:37 so `VAR += "whatever"` and `VAR_append = " whatever"` are not exactly equivalents, qschulz? Dec 11 12:41:39 Or can I specify a default somehow and use the other configuration only for system controller package? Dec 11 12:45:16 hm i wonder what the best way of saying in a tune "can't build linux" Dec 11 12:46:09 wyre: definitely not equivalents Dec 11 12:47:31 qschulz, also I'm a little bit confused about what variables are intended to use in conf files and what are intended to use in recipes 😕 Dec 11 12:50:28 building gatesgarth core-image-minimal in 80s: hot sstate and pcie nvme :) Dec 11 12:50:40 nice! Dec 11 12:50:55 ayup Dec 11 12:51:07 tell my CI runner to get a wriggle on, takes 5 minutes from clean tmp with sstate Dec 11 12:51:22 which isn't that bad but there's 11 machines to run through Dec 11 12:52:06 wyre: variables that apply to machines or distros only need to be defined in conf files, otherwise "it depends" Dec 11 12:52:36 rburton: sure, its not exactly real life numbers (yet), just starting to test with rather clean poky builds. Dec 11 12:53:29 (and by apply I mean things that are either not applicable to recipes or applicable to all) Dec 11 13:31:26 how can I define what package managemenet tool to use in the image (if I enable both RPM and DEB in my conf)? Dec 11 13:31:54 dv|2: first one builds the image Dec 11 13:32:27 rburton, sorry? Dec 11 13:32:46 where you set PACKAGE_CLASSES = "package_rpm package_deb" Dec 11 13:32:50 the first one in the list, builds the imag Dec 11 13:33:15 so that would build both rpms and debs, but rpm is used to build the image and is the installed tool Dec 11 13:34:15 rburton, I set it in my local.conf Dec 11 13:34:51 I am building several images with the same config. May I set it per-image? Dec 11 13:40:53 what is the usecase? Dec 11 13:45:43 LetoThe2nd, to have two images: one is my own repos, another may use debian/ubuntu repos Dec 11 13:46:19 that sounds extramely fishy, to say the least. Dec 11 13:48:19 LetoThe2nd, too much people says "i want ubuntu" meaning they want to install software from deb/ubuntu repos. I'm going to give it as an option while keeping my own image for true linuxois Dec 11 13:49:24 i can't see that making sense.. but hey, its your "people" Dec 11 13:51:16 Hi Everyone, forgive me for my late introduction, however I am glad to be connected with the community on #yocto. My name is Dorinda, one of the Outreachy interns and I am working on the "Add support for elfutils debuginfod" bug with my mentors Ross Burton and Paul Eggleton. I hope to learn more about Yocto project and the community, and be able to give contributions too. Thank you.🙂 Dec 11 13:52:17 LetoThe2nd, customers divided into two categories: they know linux and they want just use ubuntu on my device (because of the repos and apt/other simple set of commands they know). I won't build ubuntu. I want to give two Yocto images: one is rpm, another with apt. that's all Dec 11 13:53:26 dv|2: well i personally think the approach of building a ubuntu-replacement-underpinning is completely wrong. but again, its my opinion, and your customers. go ahead :) Dec 11 13:53:56 dorinda: howdy there! welcome on board! Dec 11 13:54:44 LetoThe2nd, they know "apt" command. that's all. Is it possible to build two images at the same time: one with DNF, another with APT? Dec 11 13:55:43 dv|2: technically on yocto, your appraoch is wrong. you should build two distinct DISTRO sets - those can define the package management system to be used. Dec 11 13:55:52 dorinda: o/ Dec 11 13:57:25 I have an embedded board that boots from a file called "boot.bin" which includes a first-stage-bootloader (FSBL) and u-boot. I have a recipe that acquires the FSBL. I have a recipe for u-boot. I also have a recipe that builds the compiler for boot.bin and puts in in ${D}${bindir} so it can be called from other recipes. Dec 11 13:57:37 LetoThe2nd, if I can define it in distro with the same local.conf - it is ok. Can I? Dec 11 13:57:54 What I'm unclear on is how I can access the output of the fsbl and uboot recipes to combine them into boot.bin... Dec 11 13:58:17 dv|2: i don't get why you're so totally insisting on "single local.conf" Dec 11 13:58:25 Is there an intermediate directory I can install their files into where a third recipe can find them? Dec 11 13:59:04 dv|2: if at all you can do a multiconfig build and with that yank out two images with different package managers in one go. Dec 11 13:59:21 ecdhe: Yes, you want to deploy the files... do_deploy Dec 11 13:59:41 Then another recipe can pull them out of ${DEPLOY_DIR_IMAGE} Dec 11 13:59:49 @LetoThe2nd yeah, thank you. I really don't know how these replies tagging work. Dec 11 14:00:31 dorinda: type the first couple of letters of the nick, then press tab :) Dec 11 14:01:14 Okay JPEW, I'll give that a try. Is that the only canonical holding tank for intermediate files? Dec 11 14:01:25 because I want to share all my build results. I already have multiconfig...So I need to add one more into my local.conf with different arch? I don't get how multiconfig can help Dec 11 14:01:41 LetoThe2nd: oh great thanks 😊 Dec 11 14:01:49 LetoThe2nd, because I want to share all my build results. I already have multiconfig...So I need to add one more into my local.conf with different arch? I don't get how multiconfig can help Dec 11 14:02:37 dv|2: i have the extremely strong impression that there is a major flaw in your construction. but i can't put the finger on it - and my motication to ge and search it is not that high too, sorry. Dec 11 14:03:45 ecdhe: No, but in your case it's the one you want.... that boot flow is pretty common, there are a few examples of it (IMX8 and Rockchip both do similar things IIRC) Dec 11 14:04:05 welcome dorinda :) Dec 11 14:04:22 qschulz: "o/" don't know what that means, but i assume its a welcome, thank you :) Dec 11 14:04:43 it's one half of a high five Dec 11 14:04:44 ecdhe: It probably should be noted that if you are using one of those SoCs (or possibly others!), you might be able to save some time by using a BSP that does that already :) Dec 11 14:04:45 \o Dec 11 14:04:58 rburton: Dec 11 14:05:01 dorinda: o/ \o. <-- two people high fiving Dec 11 14:05:16 I've used IRC for well over a decade and never seen that one before haha Dec 11 14:05:39 rburton: ohh thank you :) Dec 11 14:05:44 Should be more like o/ \o these days Dec 11 14:05:55 JPEW: this board vendor shipped with only buildroot support, I've been targetting with yocto for a while but wanted to get this additional step into the build system (instead of doing it manually) Dec 11 14:06:00 JPEW: lol Dec 11 14:06:09 paulbarker: kids these days Dec 11 14:06:17 dorinda: oh my bad, as rburton said, or just waving. \o/ is for achievements (two hands in the air), /o\ is for head-scratching/doom :) Dec 11 14:06:48 Am I allowed to change DISTRO_NAME within recipes-core/images/my-custom-image.bb ? Dec 11 14:06:58 JPEW: so do I put ${DEPLOY_IMAGE_DIR} in my SRC_URI? Or just assume that the assets I need are there already? Dec 11 14:07:15 Or is it only allowed to change DISTRO_NAME in conf/distro/mydistro.conf ? Dec 11 14:07:29 TobSnyder: what do you expect to happen when you change it in an image? Dec 11 14:07:34 TobSnyder: please apply yocto chant #1 and think about your question again. Dec 11 14:07:58 ecdhe: In your "assembly" task (which I will call do_assemble for example), you would just directly reference ${DEPLOY_DIR_IMAGE} Dec 11 14:08:02 qschulz: lol alright. funny signs though Dec 11 14:08:21 what is yocto chant #1? Dec 11 14:09:29 TobSnyder: https://www.instagram.com/p/CBgEgS_jXTD/?utm_source=ig_web_copy_link Dec 11 14:09:52 ecdhe: Then, you need to make that task depend on the recipes that generate the deployed artifacts with something like: do_assemble[depends] += "u-boot:do_deploy" Dec 11 14:10:35 ecdhe: That ensure the deploy artifacts will be present in the deploy directory by the other recipes before the do_assemble task runs Dec 11 14:10:59 * JPEW looks for an example.... Dec 11 14:12:45 ecdhe: It's not a third recipe pulling in from two others, but here is an example: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-bsp/u-boot/u-boot%25.bbappend Dec 11 14:13:20 ecdhe: This u-boot recipe pulls ATF from ${DEPLOY_DIR_IMAGE} during do_compile to add it to the u-boot image Dec 11 14:13:25 ecdhe: i think you could actually do the merging into boot.bin from the image recipe Dec 11 14:13:54 Hello everyone. I'm Ida. Sorry for the late introduction too. I'm an Outreachy intern like dorinda and I'll be improving the YP's license tracing. Dec 11 14:14:05 I create for example two images: a base image and an image containing all applications. Both of them are based on my meta-custom-dist layer. But due to the fact that in this layer there is conf/distro/mydistro.conf that sets DISTRO_NAME and DISTRO_VERSION the same version would apply to both images. But both images have to be versioned independently. This also applies to SDK that is being created - it currently only depends on variables I Dec 11 14:14:05 set in mydistro.conf (like SDK_NAME or SDKPATH) but I would like to differentiate because every image bringst its own SDK (each image might have its own libs that are needed in SDK for linking) Dec 11 14:14:09 So how to solve this? Dec 11 14:14:09 idadel: \o Dec 11 14:16:24 is there a huge advantage to use dropbear if your image is already big ? Dec 11 14:16:27 (I even ask myself if I am allowd to overwrite DISTRO) Dec 11 14:17:44 TobSnyder: IIUC, your problem is you want a different name per SDK for two images sharing the same distro and you're wondering how to do this. Right? Dec 11 14:17:49 TobSnyder: in a custom DISTRO, sure. thats what its meant for. in an image: no. Dec 11 14:20:33 idadel: howdy there too! Dec 11 14:26:52 dorinda: o/ nice to meet you! welcome to the project/community Dec 11 14:29:49 tlwoerner: \o nice meeting you too! thank you :) Dec 11 14:32:33 idadel: hi! o/ Dec 11 14:33:04 qschulz: what have you done now everyone is waving! ;) Dec 11 14:33:48 ecdhe: in fact, the example JPEW pointed you to (the one in meta-rockchip) sounds a lot like your situation: a boot binary composed of multiple pieces Dec 11 14:35:14 rburton: \o~ ~o~ ~o/ Dec 11 14:35:22 qschulz: Dec 11 14:35:38 qschulz: what's that one?! Dec 11 14:35:39 rburton: or whatever can look like a dance :p Dec 11 14:35:41 qschulz: o/ Dec 11 14:35:52 before the filesystem I compiled from yocto can load the debug symbols auto Dec 11 14:36:31 but recently I may just update my host system, the debug file compiled from yocto, it's debug symbols won't be loaded by gdb auto Dec 11 14:36:39 is there any related configure ? Dec 11 14:37:03 LetoThe2nd: We e-meet again! :) Dec 11 14:37:40 tlwoerner: o/ Dec 11 14:38:09 qschulz: lol Dec 11 14:38:18 idadel: i'm hard to miss in terms of yocto during european office times! Dec 11 14:47:32 qschulz: you are right, I want to images that are based on one distro but that should use different versions (that I also can see in the running system later on) as well as different SDKs Dec 11 14:49:50 so for SDK I guess I have to overwrite TOOLCHAIN_OUTPUTNAME or SDK_NAME but as I understand those changes have to be done in distro.conf Dec 11 14:50:14 TobSnyder: so why not create a common-distro.inc and pull it in in two distint distros, that just override the particular bits? Dec 11 14:56:39 ok so this would also be some possible way, resulting in just also creating another distro.conf in the layer that contains the application image Dec 11 14:57:46 yup. a classic approach, if you ask me. Dec 11 14:58:39 rburton: RP: Morning Dec 11 14:58:49 morning sgw Dec 11 14:59:02 Before I go digging to deep did one of you already look at the build failure ? Dec 11 15:00:24 "the build failure" Dec 11 15:00:53 * LetoThe2nd starts giggling uncontrollably, progressing into mad laughter and rolling on the office florr Dec 11 15:08:32 sgw: i haven't and RP has been out all morning, so i think its on you :) Dec 11 15:10:16 rburton: thanks, just did not want to duplicate effort. the systemd packaging failure seems interesting and really random! Dec 11 15:15:54 sgw: rburton is correct, I've not been around until now Dec 11 15:17:07 RP hope you where out for some fun and adventure! I am looking into the 3 issues from the full build. Dec 11 15:18:00 sgw: I got soaked and very muddy ;-) Dec 11 15:18:58 Thanks bluelightning, can I add SYSROOT_DIRS += "${bindir}" if we want the binary in rootfs. Dec 11 15:20:51 that means fun! Dec 11 15:23:17 JaMa: too fast for me :/ Dec 11 15:25:43 LetoThe2nd: just for my understanding your proposal would mean I will have a distro for each image probably Dec 11 15:27:14 sgw: I might agree when I warm up a bit :) Dec 11 15:27:59 If your usecase mandates this it is possible, of course Dec 11 15:28:43 psiva87: no, FILES_ is what you're looking for Dec 11 15:29:01 SYSROOT_DIRS is a way to make files available to other recipes at build time Dec 11 15:30:03 psiva87: if you want a file in your rootfs, you add it to a package with FILES_ and then add this package to your image (via IMAGE_INSTALL usually) Dec 11 15:30:19 (or if a piece of SW depends on it, RDEPENDS/DEPENDS in that recipe) Dec 11 15:31:12 If I have DISTRO_VERSION in my common.conf and in my distroA.conf and SDK_VERSION = "v${DISTRO_VERSION}" in common.conf. will it use the one defined in distroA.conf when building an image based on distroA.conf? Dec 11 15:31:26 (the question is: when will those variables be resolved) Dec 11 15:32:04 (of course with something like "require common.conf" in distroA.conf) Dec 11 15:32:22 is there some variables for busybox that maps to configure variables or do I have to patch / replace the entire busybox config for build? Dec 11 15:32:35 ( the defconfig vars) Dec 11 15:32:48 Ad0: there exists support for config fragments Dec 11 15:33:04 oh yeah I totally forgot about that, I thought it was restricted to kernel only Dec 11 15:33:08 TobSnyder: it'll work just fine Dec 11 15:33:16 thanks Dec 11 15:33:36 Ad0: it's on a per-recipe basis Dec 11 15:33:42 nice Dec 11 15:33:44 not all kernel recipes actually support config fragments Dec 11 15:33:56 Ad0: no, I think you misunderstood if you said nice :p Dec 11 15:34:04 LOL Dec 11 15:34:14 I said "nice" to the fact that you reminded me of the fragments stuff Dec 11 15:34:23 Ad0: ack Dec 11 15:34:29 sorry for being unclear Dec 11 15:34:40 also I might switch back to openssh instead of dropbear Dec 11 15:35:05 Ad0: no worries, how I phrased my sentence was also not great ;) Dec 11 15:35:10 hehe Dec 11 15:35:14 Ad0: what for? Dec 11 15:35:17 I mean I did dropbear -i -r /var/lib/dropbear/dropbear_rsa_host_key -p [127.0.0.1]:22 -p [::1]:22 -s Dec 11 15:35:32 still binds to 0.0.0.0 since I can connect from LAN Dec 11 15:35:40 tcp 0 0 :::22 :::* LISTEN Dec 11 15:36:20 seems like it completely ignores it (v2019.78 found in Warrior) Dec 11 15:36:38 it seems a bit silly to fiddle with ipchain to fix it Dec 11 15:58:24 thanks JPEW, got that working Dec 11 15:58:51 thanks tlwoerner, yes, the rockchip situation is pretty similar Dec 11 16:00:09 JPEW: I guess it's time to start bisecting the kernel :) Dec 11 16:00:36 So I got my recipe working, it depends on other recipes. For a long time I tested it with 'bitbake myrecipe'. Then I referenced it from "INSTALL_IMAGE_APPEND" in my layer.conf and went to build my image, and the build fails, saying: Dec 11 16:00:39 qschulz: Oh, I bisected pretty much all day yesterday.... it's quite puzzling :) Dec 11 16:00:46 'Package 'myrecipe' has no installation candidate' Dec 11 16:01:26 can ipk package manager be used to update the boot and kernel? Dec 11 16:02:57 I modified myrecipe.bb to include the line PROVIDES = "myrecipe" but still no luck Dec 11 16:03:36 ecdhe: Is the 'myrecipe' package created by myrecipe.bb empty (no files?) Dec 11 16:03:53 qschulz: Ad0: i think config fragments only works with kernel, not busybox? Dec 11 16:03:59 ecdhe: That happens a lot with recipes that are only a static library Dec 11 16:04:33 ecdhe: .... or recipes that only deploy something ;) Dec 11 16:05:23 JPEW: yes, it only deploys something Dec 11 16:05:41 it does have 'inherit deploy' Dec 11 16:05:43 ecdhe: Ya, in that case installing the "package" doesn't really make any sense Dec 11 16:06:19 By default, bitbake will not generate an (ipk,deb,rpm) for any package that doesn't contain any files Dec 11 16:06:32 This is the same problem bobbyJ was having yesterday Dec 11 16:06:49 yeah, and in this case I want to install files onto the FAT partition of my SD card, not the ext partition Dec 11 16:07:05 It would be nice if there was a concept of an additional filesystem Dec 11 16:07:11 Are you using wic? Dec 11 16:07:17 no? Dec 11 16:08:13 ecdhe: wic lets you do that FWIW.... I *highly* recommend using it Dec 11 16:08:39 Hi all, I'm trying to migrate a project from Zeus to Dunfell branch and I got a issue tmp/deploy/licenses//recipeinfo not found. It's a custom image recipe based on core-image-minimal (no trouble with this one) Any info about this file ? Thank you :) Dec 11 16:09:40 JPEW, looks neat Dec 11 16:11:42 It looks like exactly what I need. Except today I really just need to get the output of this build... perhaps I'll try to include a dummy file Dec 11 16:13:03 Does anyone know what the MACHINE name is for qemux86_64? Dec 11 16:13:08 Is that the correct machine name? Dec 11 16:14:16 is there a list of all yocto supported machines? Dec 11 16:18:45 ecdhe: The key is --sourceparams="loader=u-boot" on line 23: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/wic/rk3399-boot.wks#n23 Dec 11 16:18:48 matthewcroughan: you'll want to look for files with paths matching `conf/machine/*.conf` to get a list of machine names. Different layers tend to add support for different machines Dec 11 16:19:15 many layers (bsp layers) exist solely to add various MACHINEs Dec 11 16:19:26 ecdhe: Then, you can control what files are put in that partition with WKS_FILE_DEPENDS/WKS_BOOT_FILES: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/rock-pi-4.conf Dec 11 16:20:39 matthewcroughan: `qemux86-64` is a valid machine name (provided by openembedded-core) Dec 11 16:21:27 If you're using `poky`, you can find it in `meta/conf/machine/qemux86-64.conf` Dec 11 16:25:56 khem: have you seen clang segfault while linking chromium before ? Dec 11 16:26:13 khem: seems both clang10 and clang11 does Dec 11 16:34:26 JPEW: I have sdimage-bootpart.wks, it looks close to what I need, but lacks "--sourceparams="loader=u-boot" why is that flag so important? Dec 11 16:38:54 tlwoerner: no there is support for config fragments with busybox Dec 11 16:39:11 tlwoerner: see all the .cfg files in https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/busybox/busybox_1.32.0.bb Dec 11 16:41:04 matthewcroughan: find all machines in all layers by doing finding the .conf files in meta-*/conf/machine/ Dec 11 16:41:20 it's probably qemux86-64 since underscores aren't supported in machine names Dec 11 16:41:21 qschulz: awesome, thanks for the update Dec 11 16:41:33 matthewcroughan: c.f. https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/machine/qemux86-64.conf Dec 11 17:00:09 ecdhe: That tells wic to populate the (FAT?) partition with files necessary for u-boot Dec 11 17:03:25 ecdhe: Sorry, I link I pointed you in the wrong direction... Dec 11 17:03:54 You only need the --source bootimg-paritition which will copy the files specified in WKS_BOOT_FILES Dec 11 17:04:31 The --sourceparams="loader=u-boot" is only necessary if you want WKS to make a extlinux.cfg file, which will allow a default u-boot to automatically find and boot your kernel Dec 11 17:05:06 If you've modified u-boot with your own boot flow, you don't need that Dec 11 17:06:02 JPEW: which conflicts with other u-boot tooling to create extlinux.cfg files :-( Dec 11 17:06:11 (outside of wks) Dec 11 17:07:06 tlwoerner: Maybe? We never use it because we use boot scripts instead Dec 11 17:07:37 It looks like you can specify your own extlinux.cfg: bootloader --configfile="directdisk-bootloader-config.cfg" Dec 11 17:09:30 tlwoerner: I think the real advantage is that it "just works" for most of the standard use cases since it auto-detects the kernel type, boot args, etc. If you're doing anything custom, you're probably better turning it off Dec 11 17:11:58 boot scripts are the way to go there IMHO. Just turn on distro_boot in u-boot and put a boot.src file in IMAGE_BOOT_FILES Dec 11 17:12:28 Ah, darn.... ecdhe: everywhere I previously said WKS_BOOT_FILES should be IMAGE_BOOT_FILES. My bad Dec 11 17:43:45 JPEW: i'm just saying that when you fill your machine.conf file with a bunch of EXTLINUX_* variables then find that the extlinux.conf that is used has nothing to do with the variables you created, it gets confusing Dec 11 17:44:07 especially since there's no warning or indication that what you put in your config file is getting clobbered by what wks wants to do :-) Dec 11 17:44:36 My basic custom recipe soens't populate recipeinfo anyone can point me a direction to fix that ? Dec 11 17:44:37 in any case, it's somewhere on my todo list to see if the variables in one's machine.conf could be used by wks Dec 11 17:50:19 Trying yocto on my beaglebone black, I get this: "Unhandled fault: external abort on non-linefetch (0x1008) at 0xe02e6000" any idea? Dec 11 18:08:01 tlwoerner: Ah I didn't even know about those variables Dec 11 18:12:38 welp this is new file /etc/ethertypes conflicts between attempted installs of netbase-1:6.2-r0.corei7_64 and ebtables-2.0.10+4-r4.corei7_64 Dec 11 18:12:57 tsk tsk tsk Dec 11 19:36:26 v0n: sounds like some kind of alignment issue when loading from memory? thought the `linefetch` bit seems a bit more strict than normal Dec 11 19:38:49 codyps: yeah... can I be missing a kernel option or something? Dec 11 19:56:48 RP: Sorry it's taken me a while to get back to SWATing, this morning has been crazy with other stuff. There is a systemd issue in altcfg, an NFS failure with qemux86-64 and an oe-selftest fail with reproducible_builds. Dec 11 19:57:16 That's the high level, digging deeper Dec 11 20:07:04 codyps: found how to reproduce. This happens with a (custom) power reset. Hard power cycling fixes it. Might be due to some clock initialization or something. Dec 11 20:35:21 Hey, why does Yocto define a new machine "beaglebone-yocto"? Dec 11 20:36:16 because it is the reference version that we build, not to be mistaken with the official one from TI. They have different features (fewer in the yocto reference) and a different kernel, etc. Dec 11 20:43:16 hum ok, what's confusing to me is that I thought that a new machine should describe a new hardware, and in the case of yocto, the project could have just extended or overriden TI's kernel, features, packages and stuffs Dec 11 20:50:03 there are no rules about anything like that. Dec 11 20:50:09 it's just a hardware description. Dec 11 20:50:17 and no, that would be way worse Dec 11 20:50:25 ok Dec 11 20:50:28 trying to undo what a changing base does, means you chase your tail forever Dec 11 20:50:54 but isn't why yocto is designed for? extending existing machine and packages? Dec 11 20:51:08 it's a use of it, sure Dec 11 20:51:15 ok Dec 11 20:53:25 zeddii: kinda same topic, if you were selling a hw/sw product based on a beaglebone, would you define a new machine (named "beaglebone-", "beaglebone-" or simply "") or would you simply extend "beaglebone" in your company layer? Dec 11 20:54:33 it depends if I thought that I'd need to do machine specific things at some point, being able to differentiate your machine from the base one, can come in handy. Just naming it something else, doesn't mean you aren't re-using and extending another BSP, just that you want a different name for it. Dec 11 20:55:17 also what would be the best practice strategy for handling a different platform in the future (let's say the second iteration of your hardware is based on Rpi now) or even qemu? Dec 11 20:56:27 keep machine things in a separate BSP layer. That way you'd switch out the layer for the different platform when you move on. and in theory, everything else isn't impacted. Dec 11 20:56:37 (since yocto seems to be designed around the fact that you can "swap" layers to build the same software around different hardware, I feel like I have to solve this before going further with yocto, sorry for being that verbose :)) Dec 11 21:02:01 zeddii: thank you. Would you see an in-house designed daughterboard for beaglebone as a different layer (requiring the beaglebone or custom BSP layer), or as a new machine? Dec 11 21:06:48 I don't think there's a definitive answer to that, but depending on the config, the overlays, connectivity required for the daughterboard, I'd go with a separate machine (that both inherits the beagle and defines what the daughterboard needs). But I haven't looked at the TI layers in a while to see how they handle daughterboards. Dec 11 21:07:31 in general, you are going to get better board support from the vendor... that is outside the scope of what the reference platforms are trying to do Dec 11 21:07:58 we are only trying to use the reference platform to have a reasonably available hardware target Dec 11 21:08:35 there are folks that wish the machine name in poky was not beaglebone at all, but at the time it made sense Dec 11 21:09:06 but the project has no where near enough resources to deal with the thrash of official vendor support on the reference platforms Dec 11 21:09:33 either the vendor contributes that directly or we simply have a scaled back subset of features Dec 11 21:12:46 that's kind of the problem of having an "external layers" approach, compared to built-in drivers/modules/whatever, like the kernel that you can enable or not. Dec 11 21:13:46 That's why I was very skeptical to yocto at first, because manufacturers will publish their layers and forget about it, like some does with custom kernels. The support is better when it gets contributed upstream directly. Dec 11 21:29:01 zeddii: I undestand that defining a new machine for the beaglebone+daughterboard is better because in an ideal world, I would like to have my distro built for MACHINE = "custom-bbb-hw" and even MACHINE = "beaglebone" for a generic development environement not sharing the daughter board specifics because you know, IP and stuffs. Dec 11 21:29:47 (so I don't want the "beaglebone" machine to be extended in fact, because it does mean the stock public board, not a customized one.) Dec 12 00:56:20 mostly it should come down to device tree stuff? depends on wha the daughter board does Dec 12 00:56:51 but in general, you are going to be happier with the meta-ti support of BBB... trust me Dec 12 00:57:22 it's just that TI very intentionally only has one release per year Dec 12 00:57:55 so you end up with a multi-month gap of some component (like the kernel) not updating and being in a lurch Dec 12 00:58:11 and then you get tempted to use the yocto "beaglebone" machine again... Dec 12 00:58:19 it's a viscious cycle... **** ENDING LOGGING AT Sat Dec 12 02:59:56 2020