**** BEGIN LOGGING AT Fri Jan 15 02:59:57 2021 Jan 15 03:00:56 paulg, if the system is set for reproducible builds, the timestamps of the files are based on the sources Jan 15 03:17:14 fray, ok. But what sources? Doesn't make sense that bash and systemd would have the same source date... Jan 15 03:18:00 I know systemd sources are newer than 2018 as well. Jan 15 03:37:05 dunno Jan 15 03:37:16 probably the date of a specific file, like configure.ac or osmething Jan 15 03:40:09 oh well, maybe I'll snoop around later and see if I can find an explanation... not critical ; just struck me as curious. Jan 15 03:45:58 ya, look at the reproducible builds bbclass, it's PROBABLY that Jan 15 07:36:42 hello guys ! Jan 15 07:37:12 is it possible to run a task based on the ${MACHINE} value Jan 15 07:38:09 I have a recipe that uses two SRC_URI, eg: SRC_URI_machineA += "machinea.dtsi" SRC_URI_machineB += "machineB.dtsi" Jan 15 07:38:50 In the configure task I need to append machineA.dtsi to mydts.dts if machineA or machineB.dtsi otherwise Jan 15 07:44:39 yo dudX Jan 15 07:45:59 good morning Jan 15 07:49:23 thekappe: tasks and functions can be overridden like variables. You can append or prepend to one of the tasks with doconfigureappend() { ... } Jan 15 07:49:37 thekappe: The best way depends on what you want to do when Jan 15 08:18:56 olani[m], thanks. Jan 15 08:19:11 I know that I can append some extra operation to a given task Jan 15 08:19:48 but it's not clear to me if I can run a task instad of antoher based upon the MACHINE Jan 15 08:20:09 something like do_configre_MACHINE_append(){ .. } Jan 15 08:20:22 thekappe: doconfigureprepend_machineA () { cat machinea.dtsi >> mydts.dts } Jan 15 08:20:31 woha Jan 15 08:20:38 thanks Jan 15 08:21:56 thekappe: You always need to be careful with theo override order Jan 15 08:43:02 wayland recipe has RDEPENDS_${PN}-ptest += "binutils", and I have blacklisted GPLv3 packages. I'm not building ptest packages but wayland still fails. Is this expected behaviour? Jan 15 09:35:12 thekappe: you should have two different dts Jan 15 09:35:23 each one including the appropriate dtsi\ Jan 15 09:37:18 then in your machine you add your dtb (without the .dtb extension to KERNEL_DEVICETREE Jan 15 09:38:51 idadel: I'd do a -c cleanall on linux-yocto. It seems the git repo you have is corrupted Jan 15 09:54:02 @qschulz, but if I set KERNEL_DEVICETREE, the kernel recipe will try to build the dts Jan 15 09:54:18 doesn't it ? Jan 15 09:54:46 Yhe point is that since I am using an SoC I have some DT entries related to the PS and some entries related to the PL Jan 15 09:55:22 the PL entries are automatically genereated when the device-tree recipe is parsed Jan 15 09:56:37 more specifically, the pl.dtsi is generated by the recipese, hence I put together the "main.dts" including into it pl.dtsi and mymachine.dtsi, hence the main.dtb is generated Jan 15 09:58:45 so I usually added a proprer SRC_URI_append directive for the device-tree recipe to add mymachine.dtsi, and a configure_append directive to onclude the pl.dtsi and mymachine.dtsi to main.dts Jan 15 10:05:34 @thekappe: You might use the devicetree.bbclass Jan 15 10:08:39 thekappe: PL? PS? what are those? Jan 15 10:08:58 since it's a SoC it has some nodes in fpga Jan 15 10:09:08 attached to the processor (PL) Jan 15 10:09:30 and some nodes attached directly to the processor (PS) Jan 15 10:10:11 so the final dts has entries coming from both the worlds Jan 15 10:11:13 RobertBerger, Im which sense ? Jan 15 10:12:45 thekappe: if you have a finite number of combinations of PS/PL/whatever, why don't you just make a generic recipe that compiles all combination, outputing differently named DTS and request only one dtb (or more) in your machine configuration file? Jan 15 10:13:06 (i don't like the idea that a dtb named the same way is actually completely different, it's confusing) Jan 15 10:29:30 qschulz, the final dtb name is renamed by the recipe itself with the MACHINE: https://github.com/Xilinx/meta-xilinx-tools/blob/rel-v2019.1/recipes-bsp/device-tree/device-tree.bbappend Jan 15 10:33:33 in my device-tree.bbappend I just replace what it's there called system-top.dts with my MACHINE dts file Jan 15 10:34:19 @thekappe: to only deal with the device tree combinations - not kernel each time. Jan 15 10:34:40 @thekappe: how do you build your device trees normally? via the kernel recipe? Jan 15 10:34:44 nope Jan 15 10:34:51 device-tree recipe Jan 15 10:35:59 OK then you already use the devicetree.bbclass Jan 15 10:36:13 yep Jan 15 10:36:23 So I am a bit confused about your problem. Jan 15 10:38:36 also, SRC_URI_machineA += is wrong in 99% of cases Jan 15 10:38:50 you want SRC_URI_append_machineA = " file://" Jan 15 10:39:32 although... in most cases, you can just add all files even machine specific ones to SRC_URI and just not use/install them in the recipe Jan 15 12:27:28 RobertBerger,, qschulz, sorry I was in a meeting. thanks for the inputs !  I'll try to get all together ! Jan 15 13:42:59 Hello guys, I've solved the issue with the DT and moved on. thanks again. Obviously there was something else ready to popup.. Jan 15 13:43:10 I've set up the project to generate .wic and .wic.gz images. Jan 15 13:43:10 The kernel configuration has these variables set: Jan 15 13:43:11 KERNEL_CLASSES = "kernel-fitimage" Jan 15 13:43:11 KERNEL_IMAGETYPES = "fitImage" Jan 15 13:43:12 and the fitimage (kernel + dtb) is in the wic image expected partition. Jan 15 13:43:12 What I want to do now is to add also a RAMDISK to the fitImage. Searching for that I landed here: Jan 15 13:43:13 https://github.com/Xilinx/poky/blob/rel-v2019.1/meta/classes/kernel-fitimage.bbclass Jan 15 13:43:13 This class will create a ramdisk section only if INITRAMFS_IMAGE is set somewhere. So I've added the following lines to my configuration file: Jan 15 13:43:14  IMAGE_FSTYPES += " cpio.gz" Jan 15 13:43:14  INITRAMFS_IMAGE = "core-image-minimal" Jan 15 13:43:15  UBOOT_ENTRYPOINT = "0x80000" Jan 15 13:43:15  UBOOT_LOADADDRESS = "0x80000" Jan 15 13:43:16 After doing that, I run Jan 15 13:43:16 $ bitbake -c cleansstate core-image-minimal && bitbake core-image-minimal Jan 15 13:44:06 bitbake doesn't like it very much.. Jan 15 13:44:31 it complains about  3 dependency loops: Jan 15 13:44:32 1. Jan 15 13:44:32 Task .../linux-xlnx_2019.1.bb:do_assemble_fitimage_initramfs Jan 15 13:44:33 Task .../linux-xlnx_2019.1.bb:do_deploy Jan 15 13:44:33 Task .../core-image-minimal.bb:do_image_wic Jan 15 13:44:34 Task .../core-image-minimal.bb:do_image_complete Jan 15 13:44:34 2. Jan 15 13:44:35 Task .../linux-xlnx_2019.1.bb:do_assemble_fitimage_initramfs Jan 15 13:44:35 Task .../linux-xlnx_2019.1.bb:do_deploy Jan 15 13:44:35 Task .../core-image-minimal.bb:do_image_wic Jan 15 13:44:36 Task .../core-image-minimal.bb:do_image_complete Jan 15 13:44:37 Task .../linux-xlnx_2019.1.bb:do_bundle_initramfs Jan 15 13:44:37 3. Jan 15 13:44:37 Task .../linux-xlnx_2019.1.bb:do_bundle_initramfs Jan 15 13:44:38 Task .../linux-xlnx_2019.1.bb:do_deploy Jan 15 13:44:38 Task .../core-image-minimal.bb:do_image_wic Jan 15 13:44:39 Task .../core-image-minimal.bb:do_image_complete Jan 15 13:55:49 I can't figure how to fix those loops Jan 15 14:04:46 basically I have the same problem: https://stackoverflow.com/questions/55097488/circular-dependencies-issue-with-wic-and-fitimageinitramfs Jan 15 14:10:20 I was wondering if someone could gice some advice. I am struggling to make a symbolic link appear in my image. I have added the following lines in my recipe in my do_install_append(): Jan 15 14:10:39 install -d ${D}/lib Jan 15 14:10:39 lnr ${D}/usr/lib//.so ${D}/lib/.so Jan 15 14:11:20 I have added lib dir and lib for my FILES_${PN} list as well. Jan 15 14:11:47 use oe-pkgdata-util to see where it went Jan 15 14:12:03 just because you set FILES doesn't mean the default FILES haven't already claimed it Jan 15 14:27:21 Hello everyone! Does yocto have gemm benchmark recipe? Jan 15 14:28:09 chrysh: http://layers.openembedded.org/layerindex/branch/master/layers/ Jan 15 14:29:42 so if it's not in there, it does not exist? Jan 15 14:30:15 rbuton thanks for the tip I found where the file is hiding. Jan 15 14:30:21 chrysh: At a minimum, it's not any of the registered layers Jan 15 14:30:29 does nobody else want to test the floating point and matrix multiplication performance of their platform? Jan 15 14:31:34 ok, there is whetstone for floating point Jan 15 14:41:18 JPEW: new data point - its something about the precompiled header file Jan 15 14:41:47 JPEW: as soon as I rebuilt that, a broken build started giving the "right" checksums Jan 15 14:43:58 hi, JPEW, regarding yesterday's discussion, something like will be fine: https://pastebin.com/jKVnFJfs ? Jan 15 14:50:58 JPEW: the diff isn't going to work easily, " gch is basically a dump of the internal memory state of GCC" :( Jan 15 15:01:08 RP: I was pondering if PCH was causing it.... Jan 15 15:01:44 I think PCH can be disabled Jan 15 15:05:51 JPEW: CMAKE_DISABLE_PRECOMPILE_HEADERS I'm hoping Jan 15 15:08:19 rnouse: I guess... it's still weird to me :/. I'd call it something like "read-only-rootfs-delayed-postinst" or something to make it clear it's tied to r/o rootfs Jan 15 15:10:00 ok, sgtm. thanks, I'll prepare the patch Jan 15 15:13:12 JPEW: builds fine without PCH so going to disable it, have lost enough time on this... Jan 15 15:14:19 I guess I could reply the commands in the order from the logs to reproduce Jan 15 15:14:23 replay Jan 15 15:23:04 RP: Ya. I don't think we really gain too much from PCH anyway Jan 15 15:35:40 Why meta-ti/conf/machine/include/ti33x.inc defines PREFERRED_PROVIDER_u-boot in addition to PREFERRED_PROVIDER_virtual/bootloader as "u-boot-ti-staging"? Doesn't this defeat the purpose or virtual packages? Jan 15 15:35:55 of* Jan 15 15:50:55 v0n: that's how those variables are supposed to be used, they're configuring using their version of u-boot instead of the plain upstream version Jan 15 15:52:08 v0n: in a perfect world, TI wouldn't have its own fork of u-boot, but most vendors do Jan 15 15:52:25 v0n: u-boot is a "virtual" package too Jan 15 15:52:40 JPEW: I did try playing with the order of the build commands, I can't reproduce that broken gch file :/ Jan 15 15:53:34 v0n: some vendor recipes actually add `PROVIDES = "u-boot"` to their u-boot recipes Jan 15 15:53:41 which is probably the case of TI Jan 15 15:54:07 there are places where dependencies are on virtual/bootloader and some others on u-boot Jan 15 15:54:14 you need to tackle both Jan 15 15:54:33 though, technically, I'd see more PREFERRED_PROVIDER_virtual/bootloader = "u-boot" and then PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging" Jan 15 15:54:41 than both set to u-boot-ti-staging Jan 15 15:54:55 virtual/bootloader is recent, we should get things cleaned up to use it everywhere Jan 15 15:56:12 RP: I would put quotes around "recent" :p Jan 15 15:56:59 RP: There are probably cases where using u-boot in DEPENDS makes more sense than virtual/bootloader? Jan 15 15:57:11 qschulz: probably Jan 15 15:57:13 but most cases should probably be covered with virtual/bootloader I guess Jan 15 15:57:29 I nearly said "everywhere it makes sense" Jan 15 15:59:33 qschulz: I thought it was a fairly recent thing but I may have been working on this too long :) Jan 15 16:20:15 RP: virtual/bootloader was already in 4b46c1f6e891b1ddd5968536440b888661fade3e "Initial population" in 2005 :p Jan 15 16:20:41 can';t be bothered to look into the svn if it even still exists Jan 15 16:21:53 qschulz: that is a lot older than I thought! :) Jan 15 16:31:24 hello guys Jan 15 16:32:32 does someone knows what to put in a test-image-minimal-initramfs.bb recipe ? Jan 15 16:33:06 I followed the instructions at "7.10.3. Building an Initial RAM Filesystem (initramfs) " Jan 15 16:34:08 if use the core-image-minimal-initramfs.bb recipe the behaviour is very strange Jan 15 16:35:07 thekappe: define the behavior and what you were expecting instead Jan 15 16:35:20 after booting it complains about some media device, probably due to the "initramfs-module-setup-live" Jan 15 16:35:51 i just want a login shell and rsync some files Jan 15 16:36:00 i'm going mad Jan 15 16:36:26 smurray: I'm fine with meta-ti defining a u-boot-ti-staging. Having to change both PREFERRED_PROVIDER_{virtual/bootloader,u-boot} is the confusing part to me. Jan 15 16:38:11 v0n: right, see qschulz and RP's discussion, that's historical. I've seen layers use a mix, so ATM you're kind of stuck defining both Jan 15 16:55:56 indeed, meta-ti PROVIDES += "u-boot" Jan 15 17:19:04 I was thinking about trying to add and contribute support for making Git LFS fetch all of the binary blobs that will be needed at checkout-time, during do_fetch(). Right now, that only happens later during do_unpack(). Jan 15 17:19:05 From what I see in the LFS tools, this requires having a working copy. I suppose that could be a temporary copy that's destroyed right away after the fetcher finishes. Would that be a dealbreaker? Jan 15 17:20:42 mwhoosier: temp copy should be fine Jan 15 17:21:07 I didn't realise it was doing that, that is wrong :( Jan 15 17:21:16 RP: okay, I'll try to give it a look. Jan 15 17:22:35 mwhoosier: at the very least please do file a bug so we can track it Jan 15 18:08:50 RP: pretty good yield from auh this time, I think we managed to iron out the automation Jan 15 18:28:59 I'm seeing an error using devtool for my kernel recipe. It's unpacking my file into the work-shared kernel sources directory instead of my devtool workspace directory. Any ideas on how to correct this? Jan 15 18:49:29 how come beaglebone-yocto has a extlinux.conf generated for u-boot, while there's no occurrence of UBOOT_EXTLINUX* variables in meta-yocto-bsp? Jan 15 19:37:45 v0n: wic will generate an extlinux.conf file for u-boot Jan 15 19:40:30 Does anyone here understand how devtool unpacks? Jan 15 20:27:58 RP: I was wondering if we really need the libtool 2.4 patches in binutils now a days and binutils never upgrades to the new libtool as was the hope Jan 15 20:46:14 JPEW: if and only if UBOOT_EXTLINUX = "1" if I'm not mistaken, and I don't see this variable in poky/meta-yocto-bsp Jan 15 20:59:25 v0n: No, I think wic will make one regardless of that variable Jan 15 21:00:53 v0n: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source/bootimg-partition.py#n102 Jan 15 21:33:39 Hmm, does anyone know why we don't allow systemd to manage network interfaces in qemu? Jan 15 21:49:08 enick_764: I would suspect yes, very much so unfortunately Jan 15 21:59:55 enick_764: the trouble is we have OE specific libtool sysroot fixes we need **** BEGIN LOGGING AT Fri Jan 15 23:21:53 2021 **** ENDING LOGGING AT Sat Jan 16 03:00:36 2021