**** BEGIN LOGGING AT Tue Jul 07 02:59:58 2020 **** BEGIN LOGGING AT Tue Jul 07 04:29:41 2020 **** BEGIN LOGGING AT Tue Jul 07 05:22:32 2020 Jul 07 05:43:05 RP, relating to the oe-arch list discussions, is there a reason for why layer.conf's are parsed before bitbake.conf ? That was a little surprising to me as well **** BEGIN LOGGING AT Tue Jul 07 05:56:26 2020 Jul 07 06:19:52 RP, I guess it is done in this order so that bitbake.conf can be located using the constructed BBPATH, like the manual says Jul 07 09:02:02 Question about supported linux distros (development host) i guess Ubuntu 20.04 and Fedora 31/32 are not supported yet ? Jul 07 09:02:55 depends (TM) Jul 07 09:03:15 i think dunfell should build on both. Jul 07 09:04:09 Yeah i meant 3.1.1 dunfell Jul 07 09:04:51 pxfin: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf?h=dunfell#n52 Jul 07 09:05:43 Ah OK thanks for the info.. I am just starting with yocto Jul 07 09:07:00 pxfin: then its a perfect moment to watch #1 V2.0 of https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Jul 07 09:08:00 Yeah i've been watching some videos already but not this.. good thanks Jul 07 09:08:13 have fun Jul 07 09:11:33 I got errors compiling poky on Fedora 32 Jul 07 09:12:47 kidon[m]: f32 is only explicitly supported on current master. Jul 07 09:26:13 Leto is that Orden Ogan shirt in the video ;-) Jul 07 09:38:00 yup Jul 07 09:42:47 Sorry not a support question for this channel but noticed that and Vader so you must be metal music listener :) Been listening more than 35 years metal music but that's that Jul 07 09:44:03 hehe, we're pretty relaxed here, so no problem. nice somebody noticed it :) Jul 07 09:44:07 pxfin: The metal is strong in this channel Jul 07 09:45:01 paulbarker: ++ Jul 07 09:45:59 \m/ Jul 07 09:46:35 Just noticed via twitter that the OE Worshop videos from Brussels in Feb are now up: https://www.youtube.com/playlist?list=PL8IUnCBo9SB1B5rRMg7jKtqrqkCJsVCnT Jul 07 09:48:41 paulbarker: twitter is new new cool shitz! Jul 07 09:50:34 LetoThe2nd: It does the job and I find it less distracting than Facebook Jul 07 10:01:12 paulbarker: awesome! Jul 07 10:06:43 1 new failure and 2 more intermittent issues overnight :( Jul 07 10:06:54 * RP just can't keep up Jul 07 10:11:57 RP, iso-codes git revision ? Jul 07 10:12:28 kroon: that was one failure, there is a patch for that. The two intermittent issues are more of a problem Jul 07 10:12:48 I'm trying to learn how to navigate the autobuilder pages **** BEGIN LOGGING AT Tue Jul 07 10:14:46 2020 Jul 07 10:16:03 RP, are master-next build results not public ? Jul 07 10:16:20 I can only find master builds it seems Jul 07 10:16:35 kroon: Are you looking at the "console" page? Jul 07 10:16:45 kroon: https://autobuilder.yoctoproject.org/typhoon/#/console Jul 07 10:17:05 RP, ah ok, thanks Jul 07 10:17:19 was looking at "Home" Jul 07 10:17:36 kroon: The console view is our custom plugin to help visualise things Jul 07 10:18:13 rburton: meta-arm is bust with master-next btw Jul 07 10:18:30 rburton will be getting sick of me :/ Jul 07 10:22:44 Ah, testing the change in -next broke the mirror :/ Jul 07 10:22:58 which unfortunately means I just broke dunfell I expect :( Jul 07 10:25:42 This is going to be a huge pain :( Jul 07 10:26:49 RP: enjoy some https://youtu.be/ZpUYjpKg9KY Jul 07 10:28:15 Hi, https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#creating-partitioned-images-using-wic tell about 3.16.4.1. Raw Mode and 3.16.4.2. Cooked Mode for partitioning. Which one is used by default when I just call bitbake? Jul 07 10:28:51 I reckon it is Cooked Mode, right? Jul 07 10:30:53 For Cooked Mode that documentation says " All you need to provide is a kickstart file and the name of the image from which to use artifacts by using the "-e" option". The question is now how do I do that in my own yocto layer? Is there any example to look at which shows me how to change the default of image creation? Jul 07 10:31:40 Currently, I just call bitbake and get an .sdcard file to flash with dd Jul 07 10:31:56 Now I want to do my own partioning. Jul 07 10:32:36 fbre: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#wic-requirements Jul 07 10:33:59 I have created an iso image by adding IMAGE_FSTYPES = "ext4 iso" in local.conf Jul 07 10:34:21 Is there a way to configure a custom swap space without using wic Jul 07 10:34:22 fbre: the image name is passed to wic directly for you by Yocto, c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types_wic.bbclass#n35 Jul 07 10:52:09 Hi all, I have question about kernel patches, will patches be installed in a arrange given by the number heading the patch file 0001.patch , and if they are, is the 0001 first, and ie. 0002 last one to be applied? does SRC_URI arrangement mean anything? Jul 07 10:56:02 Jaks: no, they are applied in the order they appear in the SRC_URI Jul 07 10:59:51 Thanks qschulz Jul 07 11:09:48 qschulz: thanx. This line 35 is essential to understand what the yocto build does by default. That should be mentioned in the docs. Next I actually need to know an example for how to change the default to my own partioning. I have read the whole documentation chapter about partitioning but still don't have a clue what to do next in practice '=D Jul 07 11:11:13 Is there an example of how one changes the partitioning in his own bb file of his own meta layer? Jul 07 11:12:02 I mean how one changes the default partitioning **** BEGIN LOGGING AT Tue Jul 07 11:21:02 2020 Jul 07 11:40:23 Cooked Mode suggests in the docs " All you need to provide is a kickstart file". How do I provide a kickstart file? Jul 07 11:43:00 fbre: for example look at https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/ Jul 07 11:43:12 fbre: canned scripts in the wic directory Jul 07 11:46:11 g'day Jul 07 11:50:30 OK, if I make a copy of meta-ti/tree/wic/sdimage-2part.wks in my own meta layer, how do I tell the build system to take that one? Jul 07 11:51:46 Which magic .bb file must be changed in which way to configure that Jul 07 11:52:47 fbre: in your machine file should be present a WKS_FILE = Jul 07 11:54:56 I see, should I add WKS_FILE = my.wks to my machine .conf file, right? Jul 07 11:56:03 fbre: yes Jul 07 11:57:39 hi, is there a way to provide a different git URI to SRC_URI in a .bbappend file and to make BitBake prefer that one when fetching the code? Jul 07 11:59:33 This should be written in the docs more clearly. With your hints I am starting to understand what the documentation means there in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-partitioned-images-using-wic :) Jul 07 12:01:12 polaris-: prefer that one referred to what? Jul 07 12:02:02 mckoan: I want BitBake to prefer the git URI I provide in the .bbappend to the one given in the original .bb. Jul 07 12:02:16 polaris-: override SRC_URI entirely, or use _remove of the original git URI Jul 07 12:03:57 polaris-: when you define a new SRC_URI in a .bbappend file it become the one used Jul 07 12:05:05 qschulz: _remove sounds interesting Jul 07 12:06:13 mckoan: I don' Jul 07 12:06:23 t want to replace it entirely. Jul 07 12:07:11 mckoan: I basically want to use a different git server for the source. Jul 07 12:12:10 RP: what did you break now? :) Jul 07 12:13:13 rburton: u-boot upgrade Jul 07 12:17:56 qschulz: thanks for the tip! _remove is what I was after. The detailed documentation in the BB manual managed to not show up in my searches :) Jul 07 12:19:10 polaris-: know that _remove is final, you can't re-add something that is in _remove Jul 07 12:20:41 RP: so we'll consider this notice and will fix asap Jul 07 12:21:34 qschulz: Ah .. that's good to know Jul 07 12:21:41 How do I define a test partition of 10MB in such a custom .wks file? Jul 07 12:33:21 Where to define swap space in an iso image Jul 07 12:43:32 I have a meta layer of freescale. How to I find out which .wks they use? Jul 07 12:43:51 My own meta layer is on top of that Jul 07 12:45:34 As I tried to use a .wks file of poky I get an error. Function failed: do_image_wic (No boot files defined, IMAGE_BOOT_FILES unset for entry #1 Jul 07 12:46:03 I copied that poky .wks file Jul 07 12:46:21 This does not fit to the freescale way of bitbaking things Jul 07 12:47:11 Which .wks file does the layer below my own layer use by default, is the question? Jul 07 12:49:41 fbre: bitbake -e image-recipe | grep -e "^WKS_FILE" Jul 07 12:51:52 fbre: wic list images Jul 07 12:53:01 ERROR: Nothing provides 'image-recipe' Jul 07 12:53:11 returns the bitbake -e call Jul 07 12:53:43 wic list images returns a list of more than 10 entries Jul 07 12:55:16 fbre: 'image-recipe' means your image name Jul 07 12:55:57 fbre: for NXP usually it is imx-uboot-spl-bootpart Jul 07 12:58:20 I usually bitbake a core-image-minimal. So a bitbake -e core-image-minimal | grep -e "^WKS_FILE" returned core-image-minimal.imx8mqevk.wks core-image-minimal.wks Jul 07 12:58:29 Hey, i have a question about ROOTFS_POST_PROCESS_COMMAND, it looks like the generated script file overwrites PATH, and so it can't find commandos like ip, or ssh-keygen Jul 07 12:58:46 Is this the expected behaviour? Jul 07 12:59:34 fbre: what's your machine name? Jul 07 13:00:29 imx8mmini Jul 07 13:02:20 fbre: bitbake -e image-recipe | grep -e "^WKS_SEARCH_PATH" and then the first path to have the file is the one that should be used (haven't checked but that's usually how bitbake/yocto works) Jul 07 13:04:56 Is there a possibility to just bake the output of some recipes into an image like tar.gz, without kernel, init and supplementary directory structure? Jul 07 13:04:57 fbre: or maybe it's even avialble in the do_image_wic log Jul 07 13:05:52 fbre: WKS_FULL_PATH looks more like what you're looking for (I'm just reading the image_types_wic bbclass I setn you earlier :) ) Jul 07 13:06:24 WKS_FULL_PATH is empty Jul 07 13:07:12 where did you put your wks file? Jul 07 13:08:28 Until now I do not use my own wks file yet. I'm still trying to find out how freescale setups the things. And where I can find out which wks they use. Jul 07 13:09:27 I wonder because mckoan say they usually use meta-freescale/wic/imx-uboot-spl-bootpart.wks by default. Where is the setting this file should be used? Jul 07 13:09:57 imx-uboot-spl-bootpart.wks should be in WKS_FILE Jul 07 13:11:01 bitbake -e core-image-minimal | grep -e "^WKS_FILE returns WKS_FILE="core-image-minimal.imx8mqevk.wks" Jul 07 13:11:27 But I do not find such file Jul 07 13:11:43 yes, it's the default Jul 07 13:11:55 fbre: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types_wic.bbclass#n11 Jul 07 13:12:08 so grep for WKS_FILE in the meta-freescale layer Jul 07 13:12:17 probably in a machine.conf file or an image recipe Jul 07 13:14:47 fbre: IIRC mx8 still uses .sdcard and not .wic Jul 07 13:15:04 I have build linux image using yocto, I have access as a root to this image. How can I add USER ACCESS ? Jul 07 13:15:12 yes, I always dd .sdcard files Jul 07 13:15:30 But what do you mean? Is wic the wrong track? Jul 07 13:15:59 fbre: in that case, yes Jul 07 13:16:13 fbre: see my talk here https://koansoftware.com/yocto-project-with-artificial-intelligence-ml-on-nxp-i-mx/ Jul 07 13:16:15 X) Jul 07 13:17:05 mckoan: on meta-freescale, we've been moving to wic files Jul 07 13:18:31 otavio: hi. Starting from what release? Jul 07 13:23:26 I think I should ask differently: Why can't I run "ip a" with ROOTFS_POST_PROCESS_COMMAND? Jul 07 13:23:34 I have sumo IIRC Jul 07 13:24:20 mckoan: for some, I don't recall exactly Jul 07 13:25:03 otavio: but iMX8 is into meta-fsl-bsp-release Jul 07 13:27:44 tmpNick: you need the native variant of the package providing ip because `ip a` is ran on the host in ROOTFS_POST_PROCESS_COMMAND Jul 07 13:28:58 I can find imx8mmevk.conf but it does not contain a WKS_FILE entry. So it keeps not clear how freescale generates the sdcard image Jul 07 13:29:17 fbre: sdcard image isn't generated by wic IIRC Jul 07 13:29:53 fbre: look for a IMAGE_CMD_sdcard somewhere, that'll be the code hanlding your image creation Jul 07 13:30:08 OK. thanx Jul 07 13:30:24 Thank you @qschulz, `ip a` is provided by busybox and I can run it successfully on the board Jul 07 13:30:28 timeout for today. See you all + thanx Jul 07 13:30:39 Bye fbre Jul 07 13:32:04 But I still get a `command not found`error Jul 07 13:33:25 tmpNick: busybox doesn't run on your host. Jul 07 13:35:35 tmpNick: so, let us ask the real question. What are you trying to achieve in this ROOTFS_POST_PROCESS_COMMAND. For which reason(s) do you want to run `ip a`? Jul 07 13:36:06 I'm trying to run ssh-keygen Jul 07 13:36:21 `ip a`is just an example Jul 07 13:37:29 tmpNick: almost any command you wish to run in that step needs to have a recipe with a "native" bbclass. Jul 07 13:37:40 see this recipe: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/mtd/mtd-utils_git.bb?h=master Jul 07 13:37:48 See how it has BBCLASSEXTEND = "native nativesdk" ? Jul 07 13:39:35 IF you add mtd-utils-native to your depends, the binaries from the mtd-utils-native, built for your host platform, can be used in the ROOTFS_POST_PROCESS_COMMAND Jul 07 13:40:06 tmpNick: I'm not entirely sure ssh-keygen run at rootfs time is what you want (proivided you want to use it for creating keys). This means ssh-keygen will be run eveyrtime the rootfs is created thus the keys will have changed in between) Jul 07 13:42:03 qschulz: Does it sound reasonable to you, that it is a security risk if the ssh keys persist between different builds? Jul 07 13:43:31 Are you trying to avoid the time penalty of generating them on the target? Jul 07 13:45:39 Hmm, I guess you could generate them on the target Jul 07 13:47:12 tmpNick: yup, that's what you want (and save the keys on a persistent storage on the target) Jul 07 13:47:19 On my platform this takes ~40 seconds. Jul 07 13:47:27 The problem is that we have a requirement of maximal 10 second startup time... Jul 07 13:47:39 tmpNick: are you using systemd? Jul 07 13:47:42 yes Jul 07 13:47:55 Good news, then. :-) Jul 07 13:48:07 tmpNick: Have to ensure there is "good" randomness, though. Otherwise all devices might generate the same key. Jul 07 13:48:17 sshd.socket starts pretty much instantly and the keys won't be generated until the first ssh connection is made. Jul 07 13:48:43 That sounds good, so it won't slow down anything Jul 07 13:48:44 Generating ed25519 keys should be fairly cheap anyway Jul 07 13:48:46 That is, it won't affect your boot time.. but the first connection will be much slower than the others. Jul 07 13:49:24 if the keys are in persistent storage, just the first boot "out of factory" will take time Jul 07 13:49:42 (first boot or first connection, depends on the implementation :) ) Jul 07 13:49:45 qschulz: not with the default systemd stuff Jul 07 13:49:46 yeah Jul 07 13:50:26 fullstop: How would you provide a script for ssh-keygen on the first connection? Jul 07 13:50:36 tmpNick: It should be already done for you. **** BEGIN LOGGING AT Tue Jul 07 13:52:36 2020 Jul 07 13:52:58 You also save a bit of memory since sshd is not always running; it is spawned on connection. Jul 07 13:54:05 It parses sshd_config and figures out which keys you need. You can probably save some time on the first connection by only generating ed25519 keys, but this may limit what can connect to your device. Jul 07 13:54:26 But anything which does not support ed25519 is quite old now. Jul 07 13:57:01 fullstop: even in embedded systems :) ? Jul 07 13:57:41 qschulz: I know that I have plenty which don't support ed25519... ;-) Jul 07 13:57:52 and they probably never will Jul 07 13:59:13 fullstop: I was more implying that not supporting ed25519 in embedded systems would still be the norm somehow Jul 07 14:24:06 sakoman: Can we upgrade to the latest libdrm on dunfell to fixe qemu+virgl on Ubuntu 18.04 with AMD graphics? Jul 07 14:25:30 JPEW: That upgrade is in the batch of patches currently out for review Jul 07 14:25:57 So far no negative comments Jul 07 14:26:04 sakoman: Ah, sorry I should have checked Jul 07 14:26:10 No worries! Jul 07 14:27:12 sakoman: I think I've broken dunfell builds with the iso-codes change, see the list email :/ Jul 07 14:27:36 RP: OK, will look Jul 07 14:36:17 Guys in the init-install.sh script the swap space is calculated on the disk_size Jul 07 14:36:55 swap_size=$((disk_size*swap_ratio/100)) Jul 07 14:37:09 I want to calculate it based on the RAM available Jul 07 14:37:15 Is this possible? Jul 07 14:39:07 srijan_root: anything is possible, its only software after all. Jul 07 14:40:21 LetoThe2nd, very true...I meant to ask, during initial boot, can I get details of /proc/meminfo and then modify the script accordingly Jul 07 14:40:33 First poky bitbake took about 2.5 hours.. within virtualbox/Ubuntu 20.04.. maybe i should really do native Ubuntu install and/or upgrade HW Jul 07 14:41:21 srijan_root: i don't know if you can do that? technically replacing the script with soemthing custom is ok. Jul 07 14:41:42 pxfin: I bet you starved your VM right? How many CPU cores and RAM as well as disk is available? (or go for containers, it's used by many) Jul 07 14:41:44 pxfin: 2.5hrs in a VM is not that bad. Jul 07 14:42:57 LetoThe2nd: Thanks Jul 07 14:42:59 i hereby declare this to be the theme song for all in-VM-building folks: https://youtu.be/REXpzTtplZg Jul 07 14:43:08 I have 4 cpu (8 cores) I7-7700HQ and 16gigs ram of which half 8192mb ram is allocated for virtualbox and half of the cores meaning 4 Jul 07 14:43:38 during bitbake htop.. RAM were mostly 2 gigs usage Jul 07 14:44:22 qschulz.. well laptop fans were singing CPU maxed out yes Jul 07 14:45:03 pxfin: (don't worry, it does on mine too (12 cores desktop, 32GB of RAM :) ) Jul 07 14:45:57 qschulz - i went with 60 gigs Ubuntu installation but seems maybe 100+ is needed ? :) Jul 07 14:48:05 pxfin: a yocto build takes a lot of space (tarball, sstate-cache and workdir) Jul 07 14:50:43 yeah i've running ~20 different distros in virtualbox and started to learn about custom own ones.. first i was going for Linux From Scratch but decided Yocto is way more professional + bitbake is excellent.. saves you all the most of the manual work Jul 07 14:51:37 + i have many SBC:s laying around (Raspberry 1, 2, 3, 4) Oroids (C2, N2, XU4) Jul 07 14:51:50 odroids even Jul 07 14:53:36 JaMa: May I ask how the changes in Qt terms (https://www.qt.io/blog/qt-offering-changes-2020) affect the meta-qt5 layer? Jul 07 14:54:49 First bitbake was according to the video from LetoThe2nd.. i wonder what kind HW he was running since way faster Jul 07 14:55:10 pxfin: he was using a hot sstate-cache Jul 07 14:55:22 learning every day Jul 07 14:55:59 JaMa: Will the LTS versions stop receiving updates after the basic support has ended, or will we just not be allowed to use the open source licensing anymore? Jul 07 14:58:14 YPTM: trevor woerner is on Jul 07 14:58:34 YPTM: Josef is on Jul 07 14:59:21 LetoThe2nd - HAH! Neverending story i love that song Jul 07 14:59:32 YPTM: Joshua Watt is on Jul 07 14:59:48 pxfin: :) Jul 07 14:59:48 YPTM: Scott Murray is on Jul 07 15:00:30 sgw1: its a saul! Jul 07 15:00:38 YPTM ross in Jul 07 15:00:52 LetoThe2nd: dont get my started.. folk metal like Ensiferum or Moonsorrow from Finland ;-) Jul 07 15:01:03 hrm.. get me even Jul 07 15:02:32 YPTM: Randy joined Jul 07 15:02:37 TUNE_FEATURES.. this OK m64 core2 ? Jul 07 15:02:52 YPTM: armin is on Jul 07 15:04:25 rburton: yes indeed Jul 07 15:14:53 lol I almost remembered to go to th emeeting, then got distracted Jul 07 15:16:11 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13917 Jul 07 15:19:27 I still can't get it to work with BBCLASSEXTEND Jul 07 15:19:27 http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/lvm2/lvm2.inc#n27 Jul 07 15:19:56 tmpNick: what exactlya re you trying to do? Jul 07 15:21:43 I want to run ssh-keygen with ROOTFS_POSTPROCESS_COMMAND Jul 07 15:21:55 tmpNick: we told you you don't need it? Jul 07 15:22:30 Yes... But I still need to perform postprocessing of the image and I'd like to test this feature Jul 07 15:23:47 so what about this BBCLASSEXTEND, what are you doing with it, where, etc... Jul 07 15:24:29 I have a layer for openssh and a layer for the image recipe Jul 07 15:24:58 The image recipe performs the postprocessing and the openssh recipe has BBCLASSEXTEND native Jul 07 15:26:01 tmpNick: something else or that's it? Jul 07 15:26:23 Well they are both included in the conf file as layers Jul 07 15:26:45 did you tell Yocto that your image recipe needs openssh-native? Jul 07 15:27:19 Yes, but I think it includes the wrong one, because I inherit from another from core-image Jul 07 15:28:27 tmpNick: your last sentence needs to be a bit more explicit because I didn't understand what's done already Jul 07 15:28:55 LetoThe2nd is a rock-star now :-) Jul 07 15:29:13 tlwoerner: partially. Jul 07 15:29:26 I think I'll create a minimal working example, that's probably the easiest way to go. But right now I have no time, so I'll post it in ~3 hours or so again Jul 07 15:29:50 Thank you for your help so far Jul 07 15:32:17 tlwoerner - remember the old song ? https://www.youtube.com/watch?v=Gf1WT8VEZxk :) Jul 07 15:33:04 tlwoerner - besides at the movies who knows is a reference to the at the gates Jul 07 15:33:15 *GRIN* Jul 07 15:42:17 Hi everyone, Jul 07 15:43:46 I'm having problems building yocto sumo. More precisely, it fails to fetch iso-codes. The error message is the following: Jul 07 15:43:49 ERROR: iso-codes-3.77-r0 do_fetch: Fetcher failure: Unable to find revision 0a932d3e1e6d9058a6ef874c8ff1dc4a193bc030 in branch master even from upstreamERROR: iso-codes-3.77-r0 do_fetch: Fetcher failure for URL: 'git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http'. Unable to fetch URL from any source. Jul 07 15:44:29 From what I can see, it seems that the upstream repo changed their main branch to "main" instead of "master", and deleted the master branch Jul 07 15:44:41 https://salsa.debian.org/iso-codes-team/iso-codes/activity Jul 07 15:45:33 What would be the best way for me to create a bug report for this? Jul 07 15:47:29 OlivierSJ: fixed already? http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/iso-codes/iso-codes_4.5.0.bb?h=master Jul 07 15:48:43 OlivierSJ: but you might want to send a patch to backport this (http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-support/iso-codes/iso-codes_4.5.0.bb?id=6e16ef0c2e0ec2bbb862231cd84e7650bd5789af) patch to all supported branches if not already sent (dunfell does not have it yet, don't know if it;s been sent) Jul 07 15:48:47 That seems to be only for latest though. Unfortunately, we have to stay at sumo, which doesn't seem to have been fixed Jul 07 15:49:06 I see Jul 07 15:49:40 OlivierSJ: sumo isn't supported anymore, so it's your maintenance burden now :) Jul 07 15:50:07 OlivierSJ: a bbappend with SRC_URI_append = ";branch=main" should work Jul 07 15:50:28 I see! Will do. Thanks Jul 07 15:51:04 best would be to entirely replace SRC_URI with the correct value in a bbappend so that it's compatible with other bbappends if there are some or will be some Jul 07 15:51:36 ok Jul 07 15:53:42 Is there a way bitbake would use more memory in virtualbox.. again 1.7/7.7 for caching ? Jul 07 15:56:22 JPEW: yes Jul 07 15:56:57 or does it mean maxing out CPUs doesnt mean anything.. load average 12+ now Jul 07 16:10:17 I know its like newbie question but i've been coding since 80s and this is new.. so i am firstly connection sosial community.. if not its all about learning by doing **** BEGIN LOGGING AT Tue Jul 07 17:48:59 2020 Jul 07 17:54:15 Hrm.. big crash Ubuntu 20.04 has experienced internal error Jul 07 17:55:28 Pics here or some other means of error errata for Yocto? Jul 07 18:00:29 pxfin: You can post information here if you want Jul 07 18:00:59 OTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/2.8/x86_64-nativesdk-libc.tar.xz;sha256sum=a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab Jul 07 18:01:00 |############################################################################################################################| Time: 0:00:06 Jul 07 18:01:00 Missed 2554 Current 0 (7% match, 0% complete) Jul 07 18:01:01 upstream Jul 07 18:01:04 (/home/devuser/poky/meta/recipes-support/iso-codes/iso-codes_4.4.bb:do_fetch) failed with exit code '1' Jul 07 18:01:05 Summary: There were 2 ERROR messages shown, returning a non-zero exit code. Jul 07 18:01:06 ouch Jul 07 18:01:11 Err, pastebin please :) Jul 07 18:01:26 Learning ;-) Jul 07 18:01:31 pxfin: Sorry, should have been more explicit :) Jul 07 18:02:05 Maybe sometimes i am quite straight forward for solutions Jul 07 18:03:30 Sorry guys but i want solution now Jul 07 18:03:41 if you have solution Jul 07 18:04:17 pxfin: I don't, but if you post you're debugging information some where (e.g. pastebin) we can take a look Jul 07 18:04:23 Is this the problem mentioned above Jul 07 18:04:44 Sorry guys Jul 07 18:05:32 JPEW good Jul 07 18:06:03 pxfin: Ah so the problem is that the iso-codes failed to fetch? Jul 07 18:06:15 I am beginner Jul 07 18:06:26 i tried all the from the docs Jul 07 18:07:06 I think i said my development host above up there Jul 07 18:07:24 I tried to compile normile according to the docs Jul 07 18:07:45 pxfin: Your Ubuntu 20.04 host crashed with an internal error when you tried to build? Jul 07 18:08:09 no ubuntu ok but bitbake crashed Jul 07 18:08:32 Logs posted where from terminal Jul 07 18:09:05 Maybe not crashed but something was not found or something else i dont know Jul 07 18:09:31 pxfin: Right, based on the logs you posted, the iso-codes recipe failed to download the source code Jul 07 18:10:07 So how do i run normal poky x64 from Ubuntu 20.04 ? Jul 07 18:10:09 Thats what the line ".../iso-codes_4.4:do_fetch) failed with exit code '1'" means Jul 07 18:10:41 pxfin: I don't think this is related to your setup; what branch are you on? Jul 07 18:10:51 (e.g master, dunfell, zeus, etc) Jul 07 18:10:58 Should i change back to Ubuntu 18.04.3 ? Jul 07 18:11:15 Running according to the docs 3.1.1 Dunfell Jul 07 18:11:33 pxfin: Ok, I don't think changing build hosts will help Jul 07 18:11:37 j/s Jul 07 18:13:13 pxfin: Ok, so the issue is that the upstream iso-codes repo deleted it's "master" branch in favor of a "main" branch Jul 07 18:15:16 Its just desktop Ubuntu 20.04 taken to Virtualbox 6.1.10 - Virtualbox-Guest-Additions 6.1.0 installed.. then start from command line normal .. Jul 07 18:15:47 According this Jul 07 18:15:47 https://www.yoctoproject.org/docs/3.1.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html Jul 07 18:16:36 JPEW what is the problem ? Jul 07 18:16:57 pxfin: Yes, I believe your setup is correct, the problem is the iso-codes recipe is looking for a branch that no longer exists Jul 07 18:17:07 (because upstream deleted it) Jul 07 18:17:10 What i can do Jul 07 18:17:29 Right, can you find the iso-codes_4.4.bb file in the source tree? Jul 07 18:18:18 Of course Jul 07 18:19:01 * JPEW does some searching Jul 07 18:19:08 :D Jul 07 18:19:27 Maybe i can ... Jul 07 18:19:48 Ok, once you find the file, make a change like this: https://lists.openembedded.org/g/openembedded-core/message/140316 Jul 07 18:20:15 Effectively, append `;branch=main;` to the end of SRC_URI Jul 07 18:20:37 Which will tell bitbake to start looking for the "main" branch instead of the "master" branch Jul 07 18:23:58 Good I am learning bit by bit.. loving it (which means great respects for your guys) Jul 07 18:24:49 pxfin: There is a lot to learn, but glad you are enjoying it :) Jul 07 18:25:09 I love it.. i will come back to it tomorrow Jul 07 19:52:19 sakoman: we might have to port the iso-codes change quickly as people are hitting it Jul 07 19:52:59 Yup, testing the patch with the dunfell version of iso-codes right now Jul 07 19:53:15 Looks all green so far Jul 07 19:53:52 sakoman: in this case I'm tempted to speed up the normal process for the single patch Jul 07 19:54:05 Works for me Jul 07 19:54:15 sakoman: unless you like lots of email? :) Jul 07 19:54:33 No, we all hate lots of email ;-) **** BEGIN LOGGING AT Tue Jul 07 19:57:41 2020 Jul 07 19:59:03 RP: I can do an early pull request for this week's batch of patches Jul 07 19:59:38 sakoman: if you're agreeable I can just merge that one I guess, I'm not sure its worth a delay Jul 07 20:00:27 That is fine, you also could pull from https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next Jul 07 20:00:52 I haven't gotten any more comments after the first 36 hours Jul 07 20:01:05 And people are also running into the libdrm issue Jul 07 20:01:18 So this would fix both of those Jul 07 20:02:10 either is ok with me Jul 07 20:21:51 hi Jul 07 20:24:26 how can i set the default virtual machine path to a different location for docker-tool box on windows. Jul 07 20:24:52 docker-machine create -d virtualbox --virtualbox-cpu-count=2 --virtualbox-memory=4096 --virtualbox-disk-size=50000 default Jul 07 20:24:59 this command creates the default Jul 07 20:25:09 on .docker folder Jul 07 20:25:24 is it a must that the file created there? Jul 07 20:25:49 =L Jul 07 20:48:28 sakoman: if that is ready to merge I can merge it Jul 07 20:55:38 Hmm, wonder why the armv7-a tunes aren't listed in the armv7ve package archs Jul 07 20:55:54 pretty sure the latter can run the former since the latter just hast he virtualization extensions? Jul 07 21:01:58 kergoth: entirely possible its an oversight. rburton? jonmason? Jul 07 21:02:25 I ran into some issues where combinations were not complete.. Jul 07 21:02:43 probably something we need to look at eventually.. until then I ignored the 'file loaded twice' error.. :P Jul 07 21:06:39 It's on our Todo list to verify all the tunings are correct and optimal. So, it'll happen sometime this quarter Jul 07 21:10:22 jonmason: cool. Somewhere after "unbreak autobuilder"? ;-) Jul 07 21:12:21 let me know if you need any help doing it (both 32-bit and 64-bit arm).. cause for zeus I was scratching my head on a few things, but never got back to it.. Jul 07 21:23:16 good evening :) Jul 07 21:24:36 I must admit that I feel like ~18 years ago when I was getting on IRC to learn stuff. Thank you for preserving this tradition. This time I gonna leave my irc session alive, just like during old times. Jul 07 21:27:09 I've ran into another trouble with my yocto build, which will soon become a nice saga for writing up a blog post. To the point. I do have a /data mounted elsewhere and obviously system image which ships /etc. So I would like to link my wireguard configs from /data/system/etc/wireguard/wg0.conf to /etc/wireguard/wg0.conf. I've learned that ln -s doesn't work and use of ln is deprecated since quite some Jul 07 21:27:15 time. I also found a lnr in the docs, but I am getting lost with use of placeholders. Jul 07 21:27:24 I have: lnr ${D}${PERSISTENT_DATA_DIR}/system/etc/wireguard/wg0.conf ${D}${sysconfdir}/wireguard/wg0.conf Jul 07 21:27:28 but doesn't work Jul 07 21:28:07 did I put one ${D} too much? Jul 07 21:29:18 splatch: Yes Jul 07 21:29:37 Err, maybe not with lnr... Jul 07 21:29:51 fair enough, is it valid to have ln in do_install section at all? Jul 07 21:30:03 s/ln/lnr Jul 07 21:33:12 splatch: It should be, I'm not sure why that wouldn't work. Whats the failure mode? Jul 07 21:34:13 I keep on getting "No such file or directory" with different combinations. Jul 07 21:34:15 No such file or directory: '../../data/system/etc/wireguard/wg0.conf' -> '/etc/wireguard/wg0.conf' Jul 07 21:34:29 with lnr ${PERSISTENT_DATA_DIR}/system/etc/wireguard/wg0.conf ${sysconfdir}/wireguard/wg0.conf Jul 07 21:34:44 I've tried with ${D}, now without Jul 07 21:35:51 I couldn't locate use of lnr so far which would work with persistent partition. Mender has some in their recipes, but they are still based on ln calls and wired into appends Jul 07 21:36:12 splatch: You need the ${D} for sure. Any reason you can't do `ln -s ${PERSISTENT_DATA_DIR}/system/etc/wireguard/wg0.conf ${D}${sysconfdir}/wireguard/wg0.conf` ? Jul 07 21:37:05 from what stackoverflow said and recent manual only relative links are permitted Jul 07 21:37:51 oh wait, maybe I do miss FILES section! Jul 07 21:38:22 ok, I do miss it Jul 07 21:38:28 lets see with that Jul 07 21:39:09 splatch: Can you show me where is says you have to do relative links with ln? Jul 07 21:39:51 JPEW: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#migration-2.3-absolute-symlinks Jul 07 21:40:13 not sure what staged means in this context Jul 07 21:40:52 that is a really old school term in the project :/ Jul 07 21:41:39 RP: So what does it mean? Jul 07 21:42:06 it could be a fault of my do_install, I didn't do install on ${D}${sysconfdir} Jul 07 21:42:27 splatch: Ah forgot to make the directory first> Jul 07 21:43:21 reliable builds++ :) Jul 07 21:43:48 JPEW: in the sysroot directories we want relative symlinks, not absolute ones Jul 07 21:45:02 otherwise relocation of files to new sysroots in different recipes doesn't work so well (the sstate code force converts absolute links to relative ones if you don't do it) Jul 07 21:45:54 RP: Ok, I wondered.... but using an absolute symbolic link in a target recipe would be OK (although maybe not wise if it ever became a native recipe also)? Jul 07 21:46:08 JPEW: target sysroot? Jul 07 21:46:42 if its not a sysroot "staged" file it would be ok Jul 07 21:47:07 bonus points to anyone who remembers the do_stage tasks Jul 07 21:48:09 The oldest version I've ever used was 1.6, but I was so oblivious to what was going on I probably wouldn't have noticed anyway :) Jul 07 21:49:42 JPEW: I got rid of them in July 2010 so its a 10 year anniversary on the 22nd :) Jul 07 21:49:53 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=dc807f54f858419f97e211cd62fd2d30db9a80de Jul 07 21:50:20 It why we have "staging.bbclass" Jul 07 22:05:45 RP: I think it is fine to merge it, I don't expect to get any more comments Jul 07 22:05:54 Should I send a pull request? Jul 07 22:06:32 sakoman: go on then, does it by the book :) Jul 07 22:07:24 @khem: am looking at a build failure with the linux-raspberrypi recipe from meta-raspberrypi: it looks like the commit specified in the SRCREV is no longer in the rpi-5.4.y branch, which presumably indicates that a force push happened to that branch upstream. Wondering if this breaking has been a common occurrence. Jul 07 22:08:28 @khem I am after a problem with syscall 0x197 ;) Jul 07 22:09:10 Does someone else know here where the glibc recipe finds it's magic scripts to create a syscall table from? Jul 07 22:10:09 RobertBerger: aren't those in glibc itself? Jul 07 22:10:24 Well then I guess we have a serious problem ;) Jul 07 22:10:33 Let me explain. Jul 07 22:11:03 I try to build some xenomai patched kernel. xenomai patches are only avail for 4.19.x kernels. Jul 07 22:11:15 RP: by-the-book pull request sent :-) Jul 07 22:11:50 I thought that the kernel-headers recipe is used by glibc to "autobuild" the syscalls table. Jul 07 22:11:59 So I hacked it in, I guess. Jul 07 22:12:25 Still I see the syscall 407 (which came in after 4.19) Jul 07 22:12:34 RobertBerger: does a xenomai kernel use different ABIs to other kernels? Jul 07 22:12:40 Nope Jul 07 22:13:00 With xenomai I saw the problem Jul 07 22:13:04 RobertBerger: then just use recent kernel headers and make sure OLDEST_KERNEL is set to something earlier than 4.19. glibc is backwards compatible Jul 07 22:13:18 After searching some days it looks like our glibc contains syscalls which should not be there. Jul 07 22:13:27 * RP wishes people would stop messing with linux-libc-headers Jul 07 22:13:41 RobertBerger: there should be fallback code in libc Jul 07 22:14:01 I thought that the syscall tables are auto generated against some header files. Jul 07 22:14:42 I get unknown syscall. Jul 07 22:15:20 Oldest kernel is most likely far before 4.19 - by default. Jul 07 22:15:32 I'm on dunfell 3.1.1 Jul 07 22:16:24 RobertBerger: that sounds like a libc bug to me Jul 07 22:16:30 RobertBerger: which arch? Jul 07 22:16:39 arm 32 Jul 07 22:17:01 I am currently running a build Jul 07 22:17:02 RobertBerger: seems strange others haven't commented on that Jul 07 22:17:37 it's clock_nanosleep_time64 Jul 07 22:17:58 I'll see if can somehow cook another testcase except for some xenomai testcase for it Jul 07 22:19:53 RobertBerger: https://sourceware.org/pipermail/glibc-cvs/2019q4/067981.html - not sure about where __ASSUME_TIME64_SYSCALLS is eet Jul 07 22:19:54 set Jul 07 22:20:13 RobertBerger: you want that unset though... Jul 07 22:24:01 ;) Jul 07 22:24:22 we do have code along those lines in or glibc ;) Jul 07 22:24:49 I'm returning with my relative link question.. config looks almost fine, but.. Jul 07 22:24:52 RobertBerger: I've no idea without looking Jul 07 22:25:04 lnr /lib/systemd/system/wg-quick@.service ${D}${systemd_unitdir}/system/wg-quick@wg0.service Jul 07 22:25:38 blows ups whole thing, the source of link is systemd service template, later one is service shipped via package Jul 07 22:26:14 which placeholder should be used for `lib/systemd`? Jul 07 22:26:29 RP: so you say the tables are not generated by our build: /git/sysdeps/unix/sysv/linux/arm/arch-syscall.h -> AUTOGENERATED by update-syscall-lists.py. Jul 07 22:29:51 RobertBerger: I'm sure they are but you're looking at the problem the wrong way Jul 07 22:30:07 RobertBerger: if you look at the code above, you can see there is fallback code that can be conditionally enabled Jul 07 22:30:49 RP: I'll try to see which patch we'll take Jul 07 22:30:54 path Jul 07 22:31:12 RobertBerger: libc should be capable of falling back Jul 07 22:32:13 I am puzzled because I see the syscall in runtime, which most likely comes from the glibc. Jul 07 22:32:36 it should not be there Jul 07 22:37:29 RobertBerger: I can be there if there is a fallback Jul 07 22:37:37 It can be there if there is a fallback Jul 07 22:37:41 Yep Jul 07 22:38:11 RobertBerger: one llbc can be run against multiple kernels and multiple kernel versions Jul 07 22:39:26 Yep, but I thought it's built against a kernel version/some number of syscalls and you can upgrade the kernel underneath, but not downgrade Jul 07 22:40:26 If you downgrade the kernel potentially syscalls are being called which are not available in the old kernel. Jul 07 22:41:27 RobertBerger: that isn't how it works Jul 07 22:41:42 Ah OK ;) Jul 07 22:41:50 So you say it's a runtime thing? Jul 07 22:42:46 RobertBerger: the libc adapts to the kernel version its running against. That kernel is in the range of "latest linux kernel when the libc was released" to OLDEST_KERNEL Jul 07 22:43:07 OK Jul 07 22:43:23 which is why we say not to mess with linux-libc-headers and even write it in big letters in the recipe. Nobody listens Jul 07 22:43:32 zeddii: want to comment? :) Jul 07 22:43:43 hehe - I have a bug for him Jul 07 22:43:59 It need much more documentation ;) Jul 07 22:44:38 I have a couple of use cases zeddii has some already kind of ready. Jul 07 22:45:24 So you say it's nothing to worry about when I see "one" unknown syscall? Jul 07 22:46:01 RobertBerger: did you look at the patch I pointed at? Jul 07 22:46:44 RobertBerger: in the #else if does syscall(clock_nanosleep_time64) and if ENOSYS, syscall(clock_nanosleep) Jul 07 22:47:02 i.e. tries the new one, if not present, fallback to the old one Jul 07 22:47:05 this one: https://sourceware.org/pipermail/glibc-cvs/2019q4/067981.html Jul 07 22:47:14 yes Jul 07 22:49:24 yep quite a bit of compile time stuff and some error handling Jul 07 22:50:09 standard libc stuff Jul 07 22:50:19 this is what libc code looks like pretty much Jul 07 22:50:59 RP: Quick question: Bug 11351 filed in the 2.3 time frame, at which point the recipe the built bootstrap was replaced by a binary native bootstrap. The specific issue is resolved in 3.2 already, but I haven't looked how far back it was fixed. What is the correct resolution? Jul 07 22:51:34 Well hopefully quick. :) Jul 07 22:52:02 jpuhlman: Resolved fixed with an explanation of why its no longer an issue. Can we easily find out which change did that? Jul 07 22:53:09 jpuhlman: didn't ross just change that very recently? Jul 07 22:53:17 I can dig at it, basically it was a restructure of the bootstrap process. Jul 07 22:53:21 May well have. Jul 07 22:55:00 jpuhlman: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=2a7a37e70d3709a0e2ca96d0341bbde102ee9978 Jul 07 22:55:04 OTOH I am not sure any of the 410+ character tmp directories bugs are going to work. Jul 07 22:55:31 jpuhlman: 2017 so lets point at that commit and resolve Jul 07 22:56:19 Some of the m4 regeneration create a command line with 65k characters since it lists every single m4 file in aclocal iirc. Jul 07 22:56:20 can I refer a /lib/systemd/template@.service from my package if I depend on it? Jul 07 22:56:39 cause I keep getting impression that I try to link something which is not available to my pkg Jul 07 22:56:46 jpuhlman: I think there have been patches for some of those, I didn't like a lot of them for various reasons Jul 07 22:57:37 relative paths in aclocal don't work for autotools in non-standard or multiple locations :/ Jul 07 23:01:37 jpuhlman: if there is a widespread issue then its clear its not causing anyone real world problems and we could perhaps close those bugs as such Jul 07 23:01:44 Yeah it was bison-native that died. And I was wrong it was a 143k character command line in aclocal trying to run autom4te with Autoconf-without-aclocal-m4 then proceeding to list every .m4 in the aclocal directory, which seems counter productive. Jul 07 23:04:06 I know in the past we(MV) have recommended a maximum number of characters for the top of the tmp dir. That was back in the hay day when shabang issues were all over the place. Jul 07 23:04:39 jpuhlman: https://patches.openembedded.org/series/24054/# Jul 07 23:05:07 jpuhlman: think 410 was the agreed max we'd found could work Jul 07 23:05:19 "we" being Intel+WR iirc Jul 07 23:05:21 Ah. Jul 07 23:05:43 ya.. we've hit similar rpoblems at Xilinx, and set max as well to match Jul 07 23:06:54 RP: Okay Ill grab That patch and see if I can poke at the others. I didn't get much beyond that as I was only half watching it last week in the background. Jul 07 23:07:21 That seems especially egregious. :) Jul 07 23:22:37 RP: that looks like that helped. Thanks for the pointer. Should probably merge that one. :) Jul 08 01:24:05 again Jul 08 01:24:07 ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure: Unable to find revision 38edb926592954b87eb527124da0ec68d2a748f3 in branch master even from upstream Jul 08 01:24:08 in: /home/devuser/poky/build/tmp/work/all-poky-linux/iso-codes/4.4-r0/temp/log.do_fetch.3955463 Jul 08 01:24:30 git went bonkers ? Jul 08 01:26:46 My guess is someone replaced master and the revision was removed. Jul 08 01:30:52 pxfin: jpuhlman: yeah, I've been getting similar issues on other stuff Jul 08 01:31:18 They nuked master for main. Jul 08 01:31:34 Yeah Jul 08 01:32:54 Today there was talk about this.. its not fixed yet Jul 08 01:33:19 well respects to the devs Jul 08 01:35:20 Ah yeah, as usually a day behind everything. :) Looks like it should be fixed up already in poky.