**** BEGIN LOGGING AT Wed Jan 13 02:59:57 2021 Jan 13 03:37:26 dv: layer index is your friend http://layers.openembedded.org/layerindex/branch/master/recipes/?q=firefox Jan 13 03:38:29 ah responding to ancient history because my window was scrolled up Jan 13 07:34:00 goog morning Jan 13 07:34:23 mornin Jan 13 08:05:42 purple: in regards to the PR Service issue: `Can NOT get PRAUTO, exception [Errno 111] Connection refused`... I could have 6 workers at once but they all run in multiconfig with `BB_NUMBER_THREADS = "16"`... So, I assume the multiple connections to the PR service comes from all the num of tasks * num of workers... I think a simple retry 3 times in `package_get_auto_pr` should work but I guess that would be more like a Jan 13 08:05:42 workaround. Jan 13 08:20:45 Hello everyone, I've encountered yet another problem while trying to cross-compile for arm. "error: *.so uses VFP register arguments, *.o does not" I'm trying to somehow set "-mfloat-abi=" flag to either softfp or hard, but that doesn't help at all. What am I missing? Jan 13 08:47:02 mornin' Jan 13 08:55:21 morning :) Jan 13 09:00:46 which one is openembedded-layer? It's not in meta-openembedded, nor can I find it in http://layers.openembedded.org/layerindex/branch/dunfell/layers/ Jan 13 09:01:31 'networking-layer' depends on layer 'openembedded-layer' Jan 13 09:02:33 nvm, got it, it-s meta-oe Jan 13 09:02:34 Sponge5: the layer dependencies are coming from the BBFILE_COLLECTIONS variable in layer.conf Jan 13 09:04:12 qschulz: I got the dependency from adding meta-networking to my layers and IMAGE_INSTALL_append = " networkmanager" Jan 13 09:07:23 Sponge5: no, what I meant is that when you have a layer depending on another one, the dependency is specified by using the "another one"'s BBFILE_COLLECTIONS value Jan 13 09:30:19 Which network manager are you using for embedded products with wifi connectivity? Network-Manager? wicd? ConnMan? Jan 13 09:31:58 we use iwd for wireless link management and systemd-networkd for IP configuration Jan 13 09:35:33 Do you have issues with roaming? Jan 13 09:36:51 manuel1985, it depends a little on your driver. what wifi driver are you using? Jan 13 09:38:58 the question is mostly relevant if your wifi chip's firmware doesn't do roaming by itself. in that case iwd uses the CQM RSSI notification api to monitor RSSI levels. this is a little different to wpa_supplicant which I think polls using get_station. Jan 13 09:39:23 iwd also supports AP-directed roaming by subscribing to specific action frames, but I think most drivers support that? Jan 13 09:49:41 No idea which drivers we are using. We are using nvidia jetson-TX2 and are facing problems with roaming, but WiFi seems to be a quite delicate topic. Jan 13 09:52:42 ok, sounds like you would be using brcmfmac then. what kind of problems? Jan 13 09:54:11 or maybe bcmdhd, looks like that also supports the BCM4354 chipset... anyway, you will have better mileage with wpa_supplicant because that is what all the vendors test with. but note that most broadcom/cypress firmwares will do the roaming for you by default. you need to fiddle with the roam_off parameter in the firmware if you want to offload it to your userspace supplicant Jan 13 09:54:32 Our product is streaming video from a battery-powered device. When people move around and leave the coverage of an access point, streaming gets interrupted. If I understand right, roaming between accees points having the same SSID works better than switching to ones with different name. Jan 13 09:54:59 s/mileage/stability/. but iwd has a better roaming algorithm and integrates a little easier Jan 13 09:56:30 Can you be hired as consultant? Jan 13 09:58:15 Not sure if the company is up to it, but I think we have to look into more options. We are working on that issue for quite a while but GNU/Linux is not our core expertise. Jan 13 09:59:20 I already work full time so I don't know how much time I can offer but the issue you are facing is one I have dealt with a lot recently, so I will give you my email in privmsg if you like Jan 13 10:00:34 Yes please that would help us a lot ;) Jan 13 10:01:30 sure :) Jan 13 10:56:09 Hi! I have a package that I added to IMAGE_INSTALL_append. I need to restrict it to be built only for ARM architecture images. Is it possible to do so? Jan 13 10:57:51 IMAGE_INSTALL_append_arm Jan 13 10:57:51 DanmerZ: adding for a specific machine is easiest: IMAGE_INSTALL_qemuarm_append = "..." for example. Jan 13 10:58:00 LetoThe2nd: noooooooo, the machine after the append Jan 13 10:58:01 qschulz: dang. Jan 13 10:58:25 LetoThe2nd thank you, I will try it Jan 13 10:58:39 DanmerZ: don't listen to me, listen to qschulz Jan 13 10:58:41 DanmerZ: swap qemuarm and append! Jan 13 10:59:13 LetoThe2nd: I still need to find parallels with real life example to explain the append/remove stuff so that it's clearer Jan 13 10:59:29 append/prepend/override/remove/whatever :) Jan 13 10:59:51 qschulz: you know what? we're kind of the karl lagerfeld + claudia schiffer of yocto. you're karl, you know whats going on - i'm claudia, i've good the good looks! Jan 13 11:14:09 LetoThe2nd: are you calling me ugly? Jan 13 11:16:06 i called you knowledgeable. interesting what you made of it ;-) Jan 13 11:16:37 LetoThe2nd: however I prefer Claudia without a beard :-D Jan 13 11:17:05 mckoan: nah. boring. Jan 13 11:17:22 lets say i've got inner beauty. ok? Jan 13 11:34:54 LetoThe2nd: you're very pretty don't worry Jan 13 11:41:32 awwwwww Jan 13 12:19:25 i tried that first, but, sadly: Jan 13 12:19:28 https://www.irccloud.com/pastebin/PmXdz4FC/ Jan 13 12:35:33 sigbasedata? Jan 13 12:47:10 i remember seeing only sigdata files /me shrugs Jan 13 13:03:46 it is complicated (TM) Jan 13 13:23:58 qschulz: they contain the data to build bashhash Jan 13 14:42:46 hello guys ! I'm trying to setup a  multiconfig build configuration in yocto. Jan 13 14:42:47 What I've done so far is to create a new machine in my-layer/conf/machine/mymachine.conf Jan 13 14:42:47 mymachine.conf is (for now) just a copy of zynqmp-generic.conf from meta-xilinx Jan 13 14:42:48 then I've created build/conf/multiconfig/mymachineA.conf Jan 13 14:42:48 and I've set MACHINE=mymachine in mymachineA.conf Jan 13 14:42:49 Now I am wondering.. if a certain recipe has for example this line of code: Jan 13 14:42:49 SRC_URI_zynqmp = "something" Jan 13 14:42:50 how can I get that SRC_URI parsed also if my machine has a different name ("mymachine") Jan 13 14:50:19 thekappe: MACHINEOVERRIDES is your friend Jan 13 14:50:50 be **very** careful how you add an entry to it and always use bitbake -e some-recipe to check if the order is correct Jan 13 14:58:49 RP: do you think the openssl "drop support" patch is safe for dunfell yet, or are you still experiencing fallout in master? Jan 13 14:59:18 (I know the original intent of the patch was for dunfell and I just want to make sure not to lose sight of it) Jan 13 15:06:36 @qschulz, thanks Jan 13 15:07:13 sakoman: I'm not sure that qualifies as a stable change :/ Jan 13 15:07:13 after a little googling I've seen that: https://github.com/Xilinx/meta-xilinx/blob/rel-v2019.1/meta-xilinx-bsp/conf/machine/zynqmp-generic.conf (I've used this file as template file for mymachine) Jan 13 15:07:31 sakoman: I think we're ok from a fallout perspective in master Jan 13 15:07:53 has this line: require conf/machine/include/tune-zynqmp.inc Jan 13 15:08:44 in this file this variable is set: SOC_FAMILY ?= "zynqmp" Jan 13 15:09:20 in machine-xilinx-overrides.inc : Jan 13 15:09:31 RP: I agree that it doesn't match the stable change requirements, just wanted to ask since the original patch comments indicated dunfell Jan 13 15:09:40 SOC_OVERRIDES = "${@get_soc_overrides(d.getVar('SOC_FAMILY'),d.getVar('SOC_VARIANT'), d)}" Jan 13 15:09:40 MACHINEOVERRIDES  =. "${SOC_OVERRIDES}" Jan 13 15:09:49 so probably I'm good to go Jan 13 15:10:46 RP: I'm not going to take it unless someone comes up with a really good argument Jan 13 15:11:44 thekappe: probably indeed Jan 13 15:12:14 qschulz, thanks dude Jan 13 15:42:30 Is there a way to find deprecated keywords/variables? I'm upgrading a distro from 1.5 to 3.1... A lot of thing changed since... Jan 13 15:43:56 roussinm: reading the release note from 1.5 to 3.1 is a good start usually Jan 13 15:44:19 yaaa I was hoping for an automated process. That's fine I guess. Jan 13 15:56:56 zeddii: what is the level of validation/testing done for the linux-yocto-rt kernel? The reason I'm asking is that I can't get CONFIG_PREEMPT_RT=y in .config because CONFIG_KVM=y is set in the arch/arm64/configs/defconfig. So, I suspect we need to have `# CONFIG_KVM is not set` in ktypes/preempt-rt/preempt-rt.cfg. Jan 13 15:57:35 zeddii: I forgot to mention that I found this in the 5.10 version. Jan 13 16:00:14 I wanna build dunfell poky for RPi3-64 but nss-3.51.1 from meta-oe breaks, I wanna switch to nss-3.55.1, because that contains the patch I want. I tried using PREFERRED_VERSION_nss in local.conf, but bitbake says only 3.51.1 is available. Do I have to make a new layer or is there something I'm missing? Jan 13 16:04:27 dsueiro: are you manually creating config fragments? Jan 13 16:04:56 Sponge5: where did you put nss-3.55.1 in your layer? Jan 13 16:05:06 Sponge5: you have to provide a recipe for it. PREFERRED_VERSION does not magically bump versions, it just decides between recipes if multiple versions are availabe Jan 13 16:06:37 qschulz: I have some config fragments. But I have `include ktypes/preempt-rt/preempt-rt.scc` in `mymachine-preempt-rt.scc`. Jan 13 16:07:00 dsueiro: that is not my question Jan 13 16:07:30 one is supposed to create config fragments with the appropriate tasks for the linux-kernel Jan 13 16:07:49 if you create them manually, you're asking for troubles Jan 13 16:08:11 and it seems you might be doing it otherwise, most likely you would have the CONFIG_KVM line in your config fragment? Jan 13 16:08:41 I see, but I'd like to keep my meta-openembedded clean, so I have to make a layer regardless, correct? Jan 13 16:08:59 Sponge5: you anyway need a layer, there's almost no way you can avoid this Jan 13 16:09:16 qschulz: No I don't have. As I said the `CONFIG_KVM=y`is coming from the in-tree defconfig. Jan 13 16:09:54 dsueiro: and a properly created config fragment should have it Jan 13 16:10:16 qschulz: alright, thanks, in that case I'll use the patch+bbappend instead as it's less likely to break other stuff Jan 13 16:10:35 Sponge5: where do you put your path+bbappend? Jan 13 16:12:00 qschulz: What is the problem of having `# CONFIG_KVM is not set` in ktypes/preempt-rt/preempt-rt.cfg.? I can see that in this file other configs are being turned off as well. Jan 13 16:13:07 qschulz: in a custom layer, or what do you mean? Jan 13 16:13:25 dsueiro: i am challenging the way the config fragment is created, not that it is missing `# CONFIG_KVM is not set` Jan 13 16:16:02 dsueiro: we shouldn't blindly add one line and pray it works. Just use menuconfig to select the option you need, then run diffconfig IIRC Jan 13 16:16:23 and replace the fragment with the outcome of this Jan 13 16:18:14 qschulz: I'm not blindly assuming we need to turn-off it. I followed the Kconfig selection requisites and concluded that CONFIG_KVM is preventing CONFIG_PREEMPT_RT being set. Jan 13 16:23:06 dsueiro: Kconfig is some kind of build system on its own, please use the tool for it to create what you need. I understood that CONFIG_KVM is preventing CONFIG_PREEMPT_RT and that you found it. But just adding # CONFIG_KVM is not set manually to the config fragment might not just be enough. Because you could have selects/depends on that one configuration that would then re-enable it, or disable Jan 13 16:23:08 other things by defauult Jan 13 16:27:55 JPEW: that diffoscope is at 28 hours now :( Jan 13 16:29:56 RP: Yuck Jan 13 16:30:13 I think there is a way to limit how "large" it lets a dump get Jan 13 16:31:33 sgw: The QMP integration with qemu looks really good! Using that qmp library makes it a *lot* cleaner Jan 13 16:32:44 does someone know where the irc logs are? Jan 13 16:33:35 RP: we pass --no-default-limits.... which is going to make it quite slow Jan 13 16:33:42 If there is a lot of diff Jan 13 16:33:49 wherearethelogs: https://www.yoctoproject.org/irc/ Jan 13 16:33:59 yes finally! Jan 13 16:34:01 thank you! Jan 13 16:34:33 wherearethelogs: I already answered to this exact question days ago Jan 13 16:34:49 RP: There is probably some happy medium between diff size and speed we can find Jan 13 16:34:57 mckoan I couldn't find the logs, hence I couldn't find your answer :) Jan 13 16:38:32 JPEW: right, I'd hope so Jan 13 16:44:18 JPEW: thanks, but still broken as RP pointed out on the list, my testing was limited to running do_testimage and I need to change it to runtime import for oe-selftest to work Jan 13 16:45:37 qschulz: My problem is that I'm using `KCONFIG_MODE = "--alldefconfig"` Jan 13 16:53:43 sgw: it does look good from my limited review btw, will be great to get this working! :) Jan 13 17:21:49 Hello, this isn't entirely yocto related, but I've built a custom driver that should load firmware from /lib/firmware. However I get `(NULL device *): Direct firmware load for firmware.bin failed with error -2 Jan 13 17:21:49 [ 62.781789] (NULL device *): Falling back to user helper`. This is a yocto image with initramfs in it, could this somehow affect how the kernel looks for firmware? Jan 13 17:47:24 justas: -2 is no such file or directory Jan 13 17:49:44 RP: is there a good small test subset to try with oe-selftest? Jan 13 17:49:48 but /lib/firmware exists and the firmware is inside it. Perhaps I need to enable something in the kernel? Jan 13 17:52:32 is /lib/firwmare in the initramfs and available at the time the driver tries to load the firmware ? Jan 13 17:53:04 wouldn't it be clearer to have images in images/${MACHINE}/${DISTRO}/ instead of just images/${MACHINE}/? Jan 13 17:53:27 abelloni: yes, I'm loading the drivers manually using modprobe. Jan 13 17:54:32 or maybe images//, like images/beaglebone-poky-debug-tweaks/ for example Jan 13 18:12:28 hum I've added DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/yocto/" to my local.conf, it seemed to work well until do_image_wic, which failed with "output: install: cannot stat '/work/build/tmp/deploy/images/yocto/u-boot.img': No such file or directory" Jan 13 18:13:13 it seems like the u-boot recipe didn't copy the already build u-boot.img from beaglebone-yocto/ Jan 13 19:04:00 RP: In the pokybuild QA notification, are the SHA1 of oe-core and bitbake encompassed in the SHA1 of poky (e.g. could I just checkout poky?) Jan 13 19:33:37 * paulg idly wonders if anyone uses meta-yocto (i.e. "git://git.yoctoproject.org/meta-yocto") outside of poky (i.e. "git://git.yoctoproject.org/poky") Jan 13 19:36:08 paulg: I use it occasionally when I'm supporting multiple distros in a source tree Jan 13 19:37:36 So in that situation I'd have openembedded-core & bitbake already checked out along with maybe a different distro layer. Then if I want to build poky images no point cloning the same content again, may as well just add meta-yocto Jan 13 19:38:33 I see. I was just looking at the copies of meta-poky and meta-yocto-bsp (from meta-yocto) that we have in poky - done commit-by-commit, and wondering what that buys us. Jan 13 19:40:42 it's just a question of structure and how you manage your multiple git repositories, whether you want the components or the merged repo Jan 13 19:40:48 i've used both, and neither Jan 13 19:40:54 (at various times) Jan 13 19:44:05 yeah, I've never even thought of manually placing the components myself vs using the "merged" poky repo. Might be educational for me to try that. Jan 13 19:45:21 (might also end in frustration, too... hard to say. ;-) Jan 13 20:54:32 is it safe to rm -rf build/tmp/deploy/images/? Jan 13 20:59:27 it is safe to rm tmp Jan 13 21:00:40 ok Jan 13 21:01:27 abelloni: changing DEPLOY_DIR_IMAGE and building again fails at do_image_wic, this might be a bug Jan 13 21:03:45 like missing a deploy action somehow, resulting in images such as u-boot.img not found in the new $DEPLOY_DIR_IMAGE. Jan 13 21:09:53 I've changed DEPLOY_DIR_IMAGE to "${DEPLOY_DIR}/images/${DISTRO}/${MACHINE}/" because I'm building images for different machine/distro combinations for testing, but this results in missing images such as u-boot.img. Any clue? Jan 13 21:15:14 JPEW: yes Jan 13 21:16:09 paulg: its not that much different, just gets annoying when a change to OE-Core needs bitbake updating or similar Jan 13 21:16:27 the reasons are mainly historical and we need a decent tool at this point Jan 13 21:28:24 RP: any idea on the consequences of changing DEPLOY_DIR_IMAGE? I get a few ENOENT. Jan 13 21:29:25 v0n: depends where you change it to and what else it might overlap with Jan 13 21:30:54 RP: local.conf Jan 13 21:31:44 so that I can safely (in theory) build combination of poky and a custom distro for various beaglebone variants Jan 13 21:33:32 v0n: what kind of ENOENT are you seeing? Jan 13 21:33:59 v0n: seems like a reasonable idea, hard to say why its not working without seeing the errors and understanding what you set it to Jan 13 21:34:15 RP: from do_image_wic: "output: install: cannot stat '/work/build/tmp/deploy/images/poky/beaglebone-yocto/u-boot.img': No such file or directory" Jan 13 21:35:07 v0n: was this in a TMPDIR previously built with a different setting for DEPLOY_DIR_IMAGE ? Jan 13 21:35:11 RP: I'm setting this in local.conf: DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${DISTRO}/${MACHINE}/" Jan 13 21:35:53 v0n: would be interesting to know where u-boot put the img file... Jan 13 21:36:37 maybe the u-boot recipe isn't using $DEPLOY_DIR_IMAGE? It is the correct variable to modify? Jan 13 21:36:58 should be the right var and it should be using it Jan 13 21:37:14 did you previously build with a different value in this TMPDIR? Jan 13 21:38:37 yes, I did build with the default DEPLOY_DIR_IMAGE, then I changed it, rebuild, get the error, removed build/tmp/deploy/images, rebuild again and same error Jan 13 21:38:47 the u-boot.img file isn't re-deployed Jan 13 21:38:53 v0n: try a clean TMPDIR Jan 13 21:39:06 aka find build/tmp/deploy/images/ | grep u-boot.img returns nothing. Jan 13 21:39:42 RP: you mean removing build/tmp/ completely? Jan 13 21:39:52 v0n: yes Jan 13 21:41:14 wow, takes a while Jan 13 21:42:20 there will be millions of files taking up GBs in there Jan 13 21:42:28 I bet Jan 13 21:42:46 v0n: you can move it out the way and background delete if you want Jan 13 21:43:29 indeed Jan 13 21:44:47 * v0n is building again, see ya o/ Jan 13 21:45:46 kas is very handy I must admit, it's like GNU Make for yocto. Jan 13 21:47:02 hum, seems like most tasks don't need to be re-run, interesting. Jan 13 21:48:44 v0n: it will be able to pull most things from sstate Jan 13 21:49:05 RP: indeed, building was faster than deleting tmp almost Jan 13 21:50:23 RP: my new DEPLOY_DIR_IMAGE works like a charm now, thank you! I'll remember to delete tmp when I get build failure ;) Jan 13 21:50:51 v0n: not always the solution but when you change a layout like that, it might help Jan 13 21:51:50 ok Jan 13 21:53:35 I find this modification in addition to IMAGE_LINK_NAME = "${IMAGE_BASENAME}" to be clearer Jan 13 21:54:20 so that you get build/tmp/deploy/images/poky/beaglebone-yocto/core-image-minimal.wic instead of Jan 13 21:54:22 build/tmp/deploy/images/beaglebone-yocto/core-image-minimal-beaglebone-yocto.wic Jan 13 21:59:01 RP: would it make sense to suggest the above change to poky? Jan 13 22:00:07 Or eventually IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${DISTRO}"? Because having MACHINE in both basename and dirname doesn't add much value IMHO Jan 13 22:00:37 v0n: the defaults have changed, it never used to be in MACHINE directories, hence the filenames. The challenge in changing these things is it breaks things like the release scripts Jan 13 22:02:11 RP: you mean the yoctoproject releases? Aren't these scripts using the above variables? Jan 13 22:02:37 v0n: yes amd where they can they do but it isn't that simple Jan 13 22:03:19 obviously in an ideal world it would all be magic Jan 13 22:05:55 at list DEPLOY_DIR_IMAGE must contain both MACHINE and DISTRO because it contains image links like "zImage" or "u-boot.img" which can be machine and/or distro specific. Jan 13 22:08:11 v0n: most people don't build multiple distros in the same TMPDIR Jan 13 22:09:08 it is definitely a distro policy decision and for poky, we don't expect users doing that so its probably fine with just MACHINE Jan 13 22:09:59 I see Jan 13 22:10:47 especially if the distro use different libc... Jan 13 22:11:18 v0n: I understand what you mean, its just it is a rather subjective problem, others would argue DISTRO in there isn't needed Jan 13 22:11:43 I've set TCLIBCAPPEND = "" to simplify the upload of the built artifacts, but I guess I'm screwed if I switch the libc on one of the distros. Jan 13 22:14:23 OE lets you shoot yourself in the foot if that is what you want to do :) Jan 13 22:14:45 Yup, I just realized that :) Jan 13 22:19:34 RP: is it safe to set the DEPLOY_DIR_IMAGE outside of TMPDIR? Jan 13 22:19:54 v0n: er, probably? :) Jan 13 22:23:42 Hello! I ~need to rename my MACHINE, and maintain a sort of alias while the impact of that is dealt with. Jan 13 22:24:00 has anyone ever done that and have any tips? Jan 13 22:24:46 radsquirrel: MACHINEOVERRIDES is you friend Jan 13 22:25:00 RP: hey! thanks. Jan 13 22:25:14 yes but I'm thinking about external users. Jan 13 22:25:40 JPEW: I know why vulkan-samples is breaking. the reproducer needs a different pathname *length* rather than value :/ Jan 13 22:25:40 maybe a script that automatically generates a local.conf for example. Jan 13 22:26:40 RP I guess I can just have two machine.conf files with the old one including the new one. Jan 13 22:26:52 radsquirrel: yes, and then MACHINEOVERRIDES helps a lot Jan 13 22:26:56 right. Jan 13 22:27:06 well that was much easier than I thought. Thanks RP! Jan 13 22:27:15 although you probably can force MACHINE instead/too Jan 13 22:27:49 radsquirrel: we do this in distro configs with DISTROOVERIDES a lot, machine should be similar Jan 13 22:27:58 Oh, interesting Jan 13 22:28:05 RP: well in fact DEPLOY_DIR = "${TOPDIR}/deploy" instead of "${TMPDIR}/deploy" would do the job, to separate build artifacts from files ready to be deployed onto the target machine ( if that doesn't condemn my feet ;-) ) Jan 13 22:28:16 RP will peek at that. Jan 13 22:28:22 ty. Jan 13 22:28:38 RP: I can't quite handle on why that would be the case.... does it have some empty buffer for the build path length? Jan 13 22:28:43 radsquirrel: poky has an example of the distro side of it as inheritance between poky and poky-tiny iirc Jan 13 22:29:12 radsquirrel: the kas tool is used to handle the download of the meta layers and generate bblayers.conf and local.conf for you. Jan 13 22:29:15 JPEW: yes, it uses that path for source filename path lengths in logs Jan 13 22:29:46 JPEW: I'm not entirely sure this is a safe/good/working thing to do but it clearly does Jan 13 22:29:53 er, it clearly does it Jan 13 22:32:45 v0n: I was not aware of kas, thx for that pointer. Jan 13 22:32:53 JPEW: ./framework/common/logging.h:#define __FILENAME__ (static_cast(__FILE__) + ROOT_PATH_SIZE) Jan 13 22:33:07 bldsys/cmake/global_options.cmake:string(LENGTH "${CMAKE_SOURCE_DIR}/" ROOT_PATH_SIZE) Jan 13 22:33:07 bldsys/cmake/global_options.cmake:add_definitions(-DROOT_PATH_SIZE=${ROOT_PATH_SIZE}) Jan 13 22:33:26 RP: Gross Jan 13 22:33:55 JPEW: I'm not even sure this actually puts the root path in anywhere? :/ Jan 13 22:34:25 They are using pointer arithmatic to "remove" it Jan 13 22:34:54 JPEW: oh, right, yes Jan 13 22:35:51 it won't work in our case since the values in __FILE__ are altered by our CFLAGS for debug relocation Jan 13 22:36:52 so this is actually positively dangerous and broken Jan 13 22:37:15 Right, it seems like they are trying to solve a similar problem... in a very different way Jan 13 22:37:15 radsquirrel: it's kinda awesome actually, it's simply a .yml file containing the layers url, the machine, distro and recipe(s) you want to build and optionally some local.conf fragments. Then "kas build " checks out the layers, generates the .conf files, source the env script and build. The project project a container wrapper script to handle the deps. Jan 13 23:04:44 Can an .ipk package contain just a single conf file for override? Jan 13 23:09:33 JPEW: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1abd9b84a21cd8f9298a6294ffe69aff3edb424a - such fun... Jan 13 23:25:05 rburton, jonmason: Crazy long runnin arm ltp: https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/1385 :( Jan 13 23:26:29 * armpit crazy is my middle name ; ) Jan 13 23:27:04 * armpit armpit crazy kuster Jan 13 23:28:23 RP, while closing tabs I noticed the sstate tally finished in 248 minutes. We have 8.1T in sstate release archives and 30T in the active sstate. I'm about to prune the active sstate to the last 50 days. Jan 13 23:32:27 halstead: that is quite the sstate cache. Probably good to prune it a bit! :) Jan 13 23:34:56 * RP wondered how the repro issue alternated around the workers/distros. Path length (depending on pid) is a new one Jan 13 23:35:13 Yeah. It's a bit overdue. 11399678 files identified for removal. Not the largest batch we've done at all though. Jan 13 23:35:40 halstead: curious what the size change is Jan 13 23:36:08 RP, I'll tell you when it's complete. Still a few hours away though. Jan 13 23:41:37 hmm, so is this worthy of being included in a maintenance schedule? Jan 13 23:41:41 halstead: I probably didn't help by starting a build recently :) Jan 13 23:42:12 armpit: its normally automated, we just took it out of automation due to other issues a while ago and it never got put back Jan 13 23:42:43 we should try and optimise the sstate object size a bit, I'm sure there are things in there which don't need to be Jan 13 23:43:18 JPEW: vulkan-samples breaks diffoscope so well as there is a 450MB binary in there Jan 13 23:43:29 Running a build shouldn't slow this down too much. Jan 13 23:44:25 RP, I do have one disk throwing errors. I'm going to replace it after this prune. NAS performance may drop up to 20%. Jan 13 23:44:44 halstead: ok, thanks for the headsup Jan 13 23:52:24 RP: I know it's late there, I tried the importlib suggestion and it worked locally with a simple oe-selftest -t machine , is there something more? Do you want me to try an auto-builder? Jan 13 23:52:35 RP, I sorta had a feeling that was the case. Jan 13 23:53:33 sgw, be like Nike.. Just do it ; ) Jan 13 23:59:31 sgw: next step would be the autobuilder Jan 14 00:06:25 * RP -> Zzzz Jan 14 00:10:51 halstead: do I still have an AB account that's active? If so, I probably need a password reset Jan 14 00:11:09 sgw, For running builds? I'll check. Jan 14 00:15:01 sgw, PM sent. Jan 14 00:40:40 is kernel v5.4 + rootfs from fall 2020 a combo we (yocto) still care about? (normal default is v5.8 kernel) Jan 14 00:42:02 A systemd change from late August 2020 doesn't play nice with kernels older than v5.8 and I'm wondering whether to send the (systemd) fix.... Jan 14 01:58:02 paulg: I thought it was only seen in KDE Jan 14 01:58:24 but regardless we should fix it in dunfell Jan 14 01:58:28 at the least Jan 14 01:58:53 oh we may not have that new systemd in dunfell Jan 14 02:02:16 yea, I'm not sure - was hoping someone else had better track of things in their head. Jan 14 02:02:42 https://github.com/systemd/systemd/issues/16896 <---- issue Jan 14 02:02:54 https://paste.debian.net/1181048/ <--- my fix. Jan 14 02:26:23 khem: hi, in meta-qt5 d0cd7a7a70d3fe3b3041d41391c5c082d8f23a0d QMAKE_CFLAGS_ISYSTEM was removed to "Fix errors" but it seems handy to suppress warnings in qt headers? Jan 14 02:28:34 (i didn't look in the patch, i see the include_next detail now :() Jan 14 02:35:43 any known current issues with mailing lists? I'm getting... Jan 14 02:35:52 550 5.1.1. poky wasn't found at lists.yoctoproject.org. Jan 14 02:37:01 (trying to send another fix, not the systemd crap above) Jan 14 02:56:09 paulg: some classic Lennart rationalization in that systemd issue...sigh Jan 14 02:56:42 no kidding eh? kind of dripping with "My way or the highway.". Jan 14 02:57:19 User input? Bah, who cares about that. Jan 14 02:57:58 I guess he's not heard of LTS kernels **** ENDING LOGGING AT Thu Jan 14 02:59:57 2021