**** BEGIN LOGGING AT Tue Apr 20 02:59:56 2021 Apr 20 07:14:33 Why does _append / _prepend not work properly with Python functions that are not a task? Apr 20 07:14:34 python my_func_prepend () { Apr 20 07:14:34     bb.warn ('do sth fancy') Apr 20 07:14:35 } Apr 20 07:14:35 becomes Apr 20 07:14:36 python my_func () { Apr 20 07:14:36     bb.warn ('do sth fancy') Apr 20 07:14:37 def my_func (): Apr 20 07:14:37     pass Apr 20 07:14:38 } Apr 20 07:14:38 python my_func_prepend () { Apr 20 07:14:39 None} Apr 20 07:15:15 bb.warn ('do sth fancy') is never called Apr 20 09:20:10 RP: I meant the timestamp issues :) (too many topics at once :D) Apr 20 09:20:24 (timestamp in log.do_) Apr 20 09:22:30 qschulz: I know, that is harder than you'd think :/ Apr 20 09:25:54 RP: I'm not saying it's easy, I just wanted to know if there was any specific issue or just so many small issues that makes it impractical/impossible to implement? Apr 20 09:26:37 RP: just being curious Apr 20 09:31:06 rburton: damned, I'm touching insane.class, I can check that the results do appear in `bitbake optee-os -c package_qa -e`, and none of those change ever trigger a package_qa task run, it's always using the setscene - that could be a lead for why it did not break testing ? Apr 20 09:31:39 yann: maybe your distro doesn't make that check a warning Apr 20 09:31:42 or error Apr 20 09:32:21 it is in WARN_QA, I even tried to promote it to ERROR_QA, still no package_qa rerun Apr 20 09:33:44 that part of our distro matches poky Apr 20 09:37:48 rburton: the _package_qa.tgz in my sstate is strange, it is 10240 null bytes, gzipped - tar seems to accept this input, but still... Apr 20 09:38:51 45-bytes tgz, which file even reports as "gzip compressed data, from Unix, truncated" (though perhaps abusingly) Apr 20 09:40:52 ah dumpsigs says WARN_QA and friends are whitelisted, that can explay why changing them does not trigger the job, but then is that reasonable ? Apr 20 09:41:15 and "textrel" simply does not appear in the siginfo Apr 20 09:46:56 it does not seem that easy to remove those vars from a single task or a single recipe :/ Apr 20 10:43:17 hello guys ! Apr 20 10:44:06 I'm using the devicetree class to build the DT. After the build I got my dtb listed in build/tmp/work/machine/device-tree/rev/image/boot/devicetree Apr 20 10:45:10 BY the way the devicetree folder with the dtbs is not in tmp/work/machine/my-image-recipe/version/rootfs/boot Apr 20 10:49:03 thekappe: do you have KERNEL_DEVICETREE in the machine file ? Apr 20 10:50:41 mckoan, my dts file is not in kernel's directory Apr 20 10:50:59 is built outside inheriting the devicetree.bbclaa Apr 20 10:51:23 qschulz: I can't remember what the issue was, just that I tried it and it wasn't as simple as I'd thought Apr 20 10:51:32 qschulz: I think there is a patch somewhere Apr 20 10:52:29 the devicetree class install the dtbs in /boot/device tree, and I can see that beacuase the dtbs are in build/tmp/work/machine/device-tree/rev/image/boot/devicetree Apr 20 10:52:44 but they are not in the rootfs boot folder Apr 20 10:53:08 qschulz: I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue7&id=9a88d64f788ee3036869e8ca65fdde485c383798 was it Apr 20 10:53:10 thekappe: how did you make sure the device tree was pulled in by the image or when building your machine? Apr 20 10:54:13 probably that's the issue Apr 20 10:54:59 hmm, 2015. Apr 20 10:56:04 RP: I'm quite impressed how quick you were to find a commit that was pushed 4 years ago :D Apr 20 10:57:36 qschulz: I'm just happy my memory kind of works :) Apr 20 10:57:54 thekappe: it's a package, you need to add it to your IMAGE_INSTALL one way or the other, the proper way IMO is probably to add it to MACHINE_ESSENTIAL_EXTRA_RDEPENDS in your machine configuration file Apr 20 11:04:10 qschulz, yah, you were right Apr 20 11:04:19 thanks Apr 20 11:20:11 👍 Apr 20 11:39:58 "patchelf: cannot normalize PT_NOTE segment: non-contiguous SHT_NOTE sections" - the kind of error that I want to run away and hide from :/ Apr 20 11:45:10 yann: can you send a v2 with the insane skip or shall I send it on your behalf Apr 20 12:33:13 rburton: it's v3 and sent already Apr 20 12:33:56 or so I thought, you apparently did not get it :) Apr 20 12:34:41 rburton: maybe it's held in moderation, I probably did not subscribe to meta-arm ml yet Apr 20 12:36:57 ah there it is Apr 20 12:46:37 yann: what machine were you building for? Apr 20 12:46:51 nanopi-m4, aarch64 Apr 20 12:47:02 rk3399 Apr 20 12:48:59 replicates for me on demand with qemuarm64 Apr 20 12:49:05 curious if that's the difference Apr 20 13:58:40 rburton: the cpu tunes maybe ? Apr 20 14:03:43 right Apr 20 15:09:50 fray: are you still interested in prelink-cross? Apr 20 15:11:45 JaMa: you ran into issues again? Apr 20 15:12:14 I think it's still useful to many people, however I just havn't had the time with other commitments.. Apr 20 15:13:22 From a technical "it doesn't work due to XYZ", I've never been the right person to work on that stuff. Luckily I've had support from Mentor and others in the past. Apr 20 15:13:58 RP: it's still the same issue I mentioned yesterday, now I have simple reproducer but don't understand what's different in this binary which causes double free in prelink Apr 20 15:14:24 the double free itself is in the prelinker? Apr 20 15:14:33 yes, in dso_close_1 Apr 20 15:15:48 JaMa: might be a worth a bug report with the problematic binary if its easily reproduced? Apr 20 15:15:50 This is the "working" binary http://paste.ubuntu.com/p/n4W8nwghkB/ (notice 'Could not create .gnu.conflict') Apr 20 15:16:12 where is dso_close_1? Apr 20 15:16:18 (which file) Apr 20 15:16:29 and this is the same binary (but built with dunfell instead of gatesgarth where it fails http://paste.ubuntu.com/p/mfWfb2X4PX/ Apr 20 15:17:14 https://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/tree/src/dso.c?h=cross_prelink_staging#n1702 Apr 20 15:18:43 ok.. it's close_dso_1 got it Apr 20 15:20:42 for each header in the index, set scn to the section. Call elf_getdata to load the section. If it returns NULL we're out of data to load.. we then free what we just loaded Apr 20 15:21:12 sorry, we free the d_buf.. I assume the data buffer Apr 20 15:21:32 so my sugegstion is put in a check before the free(data->d_buf) to find that value. Apr 20 15:21:49 In the past we've seen sections added that become place holders and don't end up having data in them triggering a failure like this. Apr 20 15:22:13 yes, that's what was somehow lost in that pastabin, let me paste it directly from terminal Apr 20 15:22:48 https://paste.ubuntu.com/p/c5XyKXBnNS/ Apr 20 15:23:35 it's when freeing data from section 16 .dynstr, which is also mentioned, because of the overlap with section 17 before: Apr 20 15:23:51 prelink-debug/prelink: /usr/lib/image_transport/list_transports-bad: section [16 and 17] file offsets [00050315 and 00043000] not monotonically increasing Apr 20 15:24:31 does it overlap in the original? or did it overlap after the prelink? Apr 20 15:25:38 let me check, but this overlap doesn't seem to be the only difference, because I see 83 binaries with this issue even in rootfs which doesn't trigger this corrupted free Apr 20 15:26:13 corrupted free is "mythical" in behavior.. it's not going to be consistent cause it's not absolute addresses like this. You got lucky to trigger it.. Apr 20 15:26:29 Focus on the not monotonically increasing issue. That is the real failure point Apr 20 15:26:47 If the original file is like that, then there is either a bug in the linker or someone has changed something that is no longer compatible Apr 20 15:26:49 but it seems to be always on this binary even when I rebuild whole image from scratch Apr 20 15:26:59 if it's only after prelinking then prelink resizing broke Apr 20 15:27:09 interestingly it fails like this only with dunfell and only with qemux86-64 Apr 20 15:27:46 Can you try a newer (or older) binutils with dunfell? It really could be a bug in the linker Apr 20 15:28:06 and it's somehow related to spdlog library https://github.com/ros/meta-ros/commit/f08c9a3a51bf27a63a22ec39725a463d438723c3 https://github.com/ros/meta-ros/commit/f08c9a3a51bf27a63a22ec39725a463d438723c3 as previously it was enough to upgrade/downgrade spdlog to preven this prelink issue from happening Apr 20 15:28:17 (these are the steps I usually take to diagnose this stuff.. I've learned I don't have the ELF knowledge otherwise) Apr 20 15:28:47 yes, I'm building the same image with gold instead of bfd now (as it doesn't fail in other DISTRO with ld-is-gold) Apr 20 15:29:06 then will try newer binutils Apr 20 15:32:04 is prelink expected to re-order the sections? the output from readelf --all/objdump -x shows them in very different order Apr 20 15:54:44 JaMa, it MIGHT reorder.. Apr 20 15:55:07 The reorder isn't "intentional".. it's based on finding openings in the map to insert the prelink information Apr 20 16:33:00 Hi, newbie question. In meta-raspberrypi, UBOOT_MACHINE for raspberrypi4 is defined as rpi_4_32b_config. But when i look under U-Boot sources I see the file is name rpi_4_32b_defconfig. Where is the machine getting this file? Apr 20 16:33:09 _defconfig vs _config Apr 20 16:36:58 fray: looks like in this case it moved .dynstr from section 6 to section 16 between .fini and .rodata where wasn't enough space for it, will continue to debug why, here are headers before and after http://paste.ubuntu.com/p/7fTHn72sM5/ Apr 20 16:39:11 JaMa ya if things move and there isn't enough space it SHOULD detect it and stop.. Apr 20 16:40:13 it seems to happen very often for various binaries, but without this free failing in the end :/ Apr 20 16:40:43 ya, that is broken then. Overlapping sections should have been detered and triggered a failure.. (besides the whole "don't move things where there isn't space for them) Apr 20 16:41:18 about 6 or so years ago we saw this same behavior and had to fix it.. but I don't remember where. git history might give you a clue if you havn't found the code yet Apr 20 16:41:22 systemd and dbus-deamon have this overlap as well, will check in oe-core only build Apr 20 16:43:20 I think this part works OK, it's detected dorrectly in check_dso and then it prevents prepare_write_dso/write_dso Apr 20 16:46:26 https://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_staging&id=f9975537dbfd9ade0fc813bd5cf5fcbe41753a37 Apr 20 16:46:42 the other thing to look at is libelf.. long ago we definitely found problems with that Apr 20 16:47:22 ya, thats what I was remembering Apr 20 16:53:26 I would like to have my yocto-created distribution connect to the internet through a LTE modem. Is there some software package which provides an interface to set, change PIN, PUK and such? Apr 20 16:53:54 connman used to be able to do some or all of that, but I've not tried it in a few years Apr 20 16:54:20 I know about mmcli (ModemManager) and nmcli (NetworkManager) but I thought there might be some abstraction layer making things easier. Apr 20 16:54:46 that is what connman does.. abstracts.. like like networkmanager can do Apr 20 16:55:02 fray: Is connman still active? https://01.org/connman looks pretty dead to me. "You are not authorized to access this page." Apr 20 16:55:23 like I said, I've not used it in a few years.. I don't know Apr 20 16:55:28 ok thx Apr 20 17:00:12 manuel1985, there is https://git.kernel.org/pub/scm/network/connman/connman.git/ Apr 20 17:00:21 they keep making release Apr 20 17:04:21 Has anyone some recommendations on network managers? Our product is using NetworkManager, but tbh I don't like it much. Yes fray you said you were using connman a few years ago, but due to reasons? Apr 20 17:09:23 systemd-networkd is good if you live in systemd land Apr 20 17:10:49 fray: this is interesting https://sourceware.org/legacy-ml/elfutils-devel/2018-q3/msg00092.html this is from https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/elfutils/files/0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch Apr 20 17:13:39 removing the free() on data from elf_getdata definitely fixes the issue I'm seeing Apr 20 17:15:12 Robert Yang (one of the repliers) would have a good understanding of what might be happening. So ther eis a good chance his analysis is good Apr 20 17:15:57 the question is.. how (in prelink) do we identify if the d_buf is owned by "us" or readelf.. etc Apr 20 17:16:31 but the same sort of check might be reasonable in prelink Apr 20 17:17:53 (btw I probably wouldn't have found that reference.. good job finding it!) Your google foo is strong Apr 20 17:24:29 I've sent Robert an e-mail Apr 20 17:24:57 I've noticed that patch when comparing elfutils in dunfell and gatesgarth, the rest was easy even without foo Apr 20 17:25:52 he's in Beijing. So he's likely offline by now.. Apr 20 17:27:07 still doesn't explain why prelink decides to move .dynstr section on one binary (and causes non.monotonic error message) and on another it refuses to create .gnu.conflict stright away, when the space between .fini and .rodata seems to be almost the same in both binaries, will investigate further Apr 20 17:27:41 no rush, we can disable prelink in this build as well (as we did in other builds already long time ago) Apr 20 17:29:42 I just wanted to finally figure out what spdlog does to trigger this (as I refuse to try finding "compatible" version of spdlog again, like I did 2 times before just to work around this) Apr 20 17:35:10 ya.. the moving it isn't unexpected.. but the non.monotonic is a bug of some kind Apr 20 17:35:30 when we added/updated the check it was determined something in the linker changed, but we could never figure out "what" Apr 20 17:39:06 what should I do to avoid the do_package_write_ipk tasks? I do not use a package manager. Apr 20 17:48:36 packages are the intermediate format for creating a rootfs. If the file(s) end up in a rootfs, you need a package manager -- but then never have to use the package manager or packages on the target itself. they're just intermediate archives w/ dependency metadata Apr 20 18:06:05 RUNTIMELIBITM is a variable defined in poky/meta/recipes-devtools/gcc/gcc-runtime.inc. There is also a variable RUNTIMELIBITM_riscv32. Is this called an "override"? Apr 20 18:06:15 an architecture-specific override, in this case? Apr 20 18:07:05 just looking to clarify terminology Apr 20 18:56:02 * sgw1 is trying to understand why running oe-selftest -r runtime_test.TestImage.test_testimage_virgl_gtk_sdl vs then using the created build dir to run the same via do_testimage is giving different results from different tests ! Apr 20 18:56:22 RP: rburton: ^^^ ??? Apr 20 19:02:45 to configure the ssh server (change the default port, etc.) should I bbappend the openssh recipe, or is there something fancy that I'm not aware of? Apr 20 19:41:19 yates: yes its the way to do overrides Apr 20 20:04:49 vdl: yes you can just override sshd_config via a bbappend Apr 20 20:06:43 khem: thanks. Should I bbappend openssh, or openssh-sshd? Apr 20 22:47:38 I have a simple recipe to package an mnt-data.mount unit file, but I get this: Apr 20 22:47:43 ERROR: mnt-data-1.0-r0 do_package: Didn't find service unit 'mnt-data.mount', specified in SYSTEMD_SERVICE_mnt-data. Apr 20 22:48:30 even though I properly add FILESEXTRAPATHS_preprend := "${THISDIR}/files:" and SRC_URI += "file://${PN}.mount" Apr 20 22:49:17 And my recipe resides in recipes-core/mnt-data/mnt-data.bb and the unit in recipes-core/mnt-data/files/mnt-data.mount Apr 20 22:53:48 sgw1: I suspect there is configuration being added which you're not adding back when you run it manually? Apr 20 22:57:54 OK found it, systemd.bbclass is very strict regarding where the unit is installed. Apr 20 22:58:20 RP: I have been trying to figure that out for sure. It only happens on the centos machines which is really frustrating. halstead might be creating me an oe-selftest with only the virgl test enabled. Apr 20 22:58:51 sgw1: you can do that by pushing a helper contrib branch just doing that Apr 20 23:08:00 Yeah, I think he was looking into that, I will if is not able. Finally made some ceph/cmake progress today also. (removed a sanity check, which did not have all the settings propagating correctly). Apr 20 23:36:29 For a given repository that contains multiple meta-layers with image recipes in more than one meta-layer, is multiconfig and BBMASK the best practice for enabling images in certain meta-layers to exclude other meta-layers? Apr 20 23:37:11 It seems like it is, but I was also wondering if there is a simpler way to maintain a consistent build, but to allow certain meta-layers to be excluded for certain images. Apr 20 23:44:49 sgw1: if you want me to sort a helper branch let me know Apr 20 23:50:35 RP: you have enough on your plate, I will work it out, probably good for me to refresh my memory on doing it. Apr 20 23:51:04 You might remember I had an AB instance running here at home at one point. Apr 20 23:58:50 sgw1: offer is there of you need it (planning to sleep now though!) Apr 20 23:58:55 if Apr 21 00:10:04 resoum: usually, its achieved with different distro configs, you can also thing of creating a workspace setup where layers are included only if they exist in a checkout tree. But I think its best to maintain consistent metadata set so fixed layers for your distro goes long way in maintaining it properly Apr 21 00:11:27 BBLAYERS =+ "${@'${TOPDIR}/meta-xxx' if os.path.isfile('${TOPDIR}/meta-xxx/conf/layer.conf') else ''}" Apr 21 00:11:30 something like thisi Apr 21 00:11:50 then you can control what layers get checked out for given project Apr 21 02:13:55 khem: In this case though, all of the layers are in one repository, so it would not be possible to use a checkout tree so far as I can see. The problem is that images in meta-x should not be tained by meta-y, but images in meta-x and meta-y use the same distro config. So either we have to swap bblayers.conf files, or perhaps use multiconfig and BBMASK out the offending layer. Apr 21 02:50:31 hey guys, it seems like a variable from an image recipe that I require isn't taken into account. Is that possible? **** ENDING LOGGING AT Wed Apr 21 03:01:26 2021