**** BEGIN LOGGING AT Thu Aug 06 02:59:57 2020 **** BEGIN LOGGING AT Thu Aug 06 04:09:43 2020 Aug 06 06:47:00 Hi, I faced a issue during glibc libraries relocation because file size for interpreter in program header was 0x42. I fixed by updating interp.c in elf which will update size during linking.But I am curious where the size 0x42 is set Aug 06 06:50:49 I am not finding where the p_filesz is set to 0x42...is it done individually at each library?🤔 Aug 06 07:25:30 hello Aug 06 07:25:58 how long will 3.1 be supported? Generally, is there a place where i can see this info for all releases? Aug 06 07:27:19 cornel: https://wiki.yoctoproject.org/wiki/Releases Aug 06 07:28:55 smurray, it is not written when the EOL is planned for each release Aug 06 07:29:44 cornel: ah, sorry, thought it was in that table Aug 06 07:31:02 cornel: AFAIK the answer for 3.1 is 2 years ATM, but could be longer if someone steps in to help support it Aug 06 07:31:36 cornel: I believe this is the current explanation of the release strategy: https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Aug 06 07:40:36 yo dudes. Aug 06 07:40:41 #justsayin Aug 06 07:50:21 LetoThe2nd: good morning jester Aug 06 08:12:44 smurray, thank you. unfortunately the info i'm looking for seems to be missing. Aug 06 08:27:14 it says though that the LTS are initially supported for two years Aug 06 08:32:16 cornel: what is the exact question? Aug 06 08:35:31 LetoThe2nd,how long will 3.1 be supported? Generally, is there a place where i can see this info for all releases? Aug 06 08:36:05 like in having the estimated EOL in a table Aug 06 08:37:24 cornel: well there is no such reliable information as it very much depends on if somebody steps up to do the work. Aug 06 08:38:05 cornel: so unlike "bigger" projects, AFAIK we do not have a hard, guaranteed support scheme. usually it is "the last two releases", and LTS at least two years. Aug 06 08:39:36 cornel: warrior is out of support for example currently. however, there is sombody who is interested in maintining it at the moment. hence, it might see that state again. but then on the other hand, this "support" does not guarantee any specific response time or security levels. Aug 06 08:42:23 thank you LetoThe2nd Aug 06 08:55:55 cornel: The project aims to choose an LTS release every two years. Aug 06 08:56:07 https://www.yoctoproject.org/yocto-project-long-term-support-announced/ Aug 06 08:58:01 thank you mckoan Aug 06 09:43:11 Hi, has anyone enabled DNS over TLS / DNS over HTTPS in their Yocto builds? If so, which resolver did you use? Aug 06 09:44:50 I am reluctant to use systemd-resolved's DNS over TLS, because in warrior there is systemd241 only and DNS over TLS was implemented properly in 246 **** BEGIN LOGGING AT Thu Aug 06 11:00:15 2020 Aug 06 11:08:34 hello all. In zeus i am adding to a bsp image the "EXTRA_IMAGE_FEATURES += "read-only-rootfs"" but at first boot, systemd fails with errors as it try to remount "rw", and other errors as systemd thing system is rw. Any link to study is welcome Aug 06 11:50:52 angelo__: my first bet would be looking at the bsp if it does something to systemd. Aug 06 11:52:16 LetoThe2nd, thanks, checking Aug 06 12:16:44 Hi, my yocto Linux is on a SD card which is mounted as readwrite-directory / (/dev/mmcblk1p2 on / type ext4). Do you know a documentation page which explains how to mount it just read-only as lower layer of an overlay filesystem (overlayfs) and to use a readwrite upper layer then? Aug 06 12:20:02 And /etc/fstab here just contains an entry: "/dev/root / auto defaults 1 1". I don't know where the mounting of my /dev/mmcblk1p2 actually is configured. Aug 06 12:20:04 fbre: nothing out in public that i knew of. Aug 06 12:20:43 fbre: the assignment to /dev/root usually happens through the kernel commandline (see /proc/cmdline) Aug 06 12:21:10 LetoThe2nd: ah OK. thanx Aug 06 12:31:29 zeddii: around? Aug 06 12:31:43 zeddii: the config analysis thing in master-next is breaking my kernel Aug 06 12:43:45 here. breaking, as in. it finds something and warns, or the tool won't even run ? Aug 06 12:43:58 if you send me the config details, I can do a local build and debug. Aug 06 12:44:08 python stacktrace Aug 06 12:44:13 one sec and i'll get back to you Aug 06 13:06:31 RP: can you drop my [kernel-yocto: enhance configuration queue analysis capabilities] from master-next ? I'll send a v2 later today once I've debugged Ross' issue. Aug 06 13:06:51 I'll grab your fix for the bb.debug as well, and squash it into the v2. Aug 06 13:11:52 zeddii: ok Aug 06 13:13:19 but I have all the arches working for 5.8 headers and the kernel-dev tests. as you could see from my stream of patches yesterday. Aug 06 13:13:37 only strace fixes to send today, and I'm just double checking it. Aug 06 13:13:59 zeddii: things ran through the autobuilder cleanly too Aug 06 13:14:11 meta-arm and meta-intel not withstanding Aug 06 13:15:47 yah. it's some sort of race on a file. or a task ordering I missed. I don't expect v2 will be much different, but at least I'll have tested them here to know. **** BEGIN LOGGING AT Thu Aug 06 13:27:57 2020 Aug 06 13:47:25 I would like to create a disk using wic with 4 partitions (/boot, /, /recovery, /data) whereby /data should automatically grow to the remaining disk-space Aug 06 13:47:49 but it seems the built-in wic doesn't support `--grow` for part command Aug 06 13:48:01 and idea how to reach that goal? Aug 06 13:48:12 s/^and/any/ Aug 06 14:03:19 sno: reside the partition at first boot Aug 06 14:03:30 s/reside/resize Aug 06 14:17:48 mckoan: let's call that Plan F :) Aug 06 14:19:51 sno: let me know if you find a plan B then ;-) Aug 06 14:20:22 :D Aug 06 14:30:21 mckoan: if no sane option exists, maybe sending patches would be suitable Aug 06 14:36:45 RP: any point to the wic issue? **** BEGIN LOGGING AT Thu Aug 06 15:06:44 2020 Aug 06 15:21:00 sno: no idea Aug 06 15:21:13 sno: outside my remit Aug 06 15:26:22 RP: would a patch to introduce such a --grow accepted? Aug 06 15:26:45 RP: did you had a chance to read my replies wrt. SDK? Aug 06 15:27:01 * sno has to run soon, so we cannot discuss it today Aug 06 15:27:15 sno: I did read them. I thought I'd proposed a solution so I didn't quite understand them Aug 06 15:28:25 RP: Sure you did and I checked the same before I created them - in both cases your and mind poky/meta seems to behave differently :) Aug 06 15:29:14 I do not understand why the paths are that weird Aug 06 15:30:00 sno: its relatively simple, buildtools just hardcodes what it needs and dates before the generic mechanism was added Aug 06 15:30:15 sno: could do with some cleanup Aug 06 15:32:15 RP: I'd like to dig into that deeper than tomorrow morning, I don't get how I can do this with which cleanup Aug 06 15:32:19 I need some hints Aug 06 15:33:45 and I do not see the `rm -f` you talked about - in my SDK the openssl.sh still exists in buildtools/sysroots/*pokysdk*/environment-setup.d/ Aug 06 15:34:42 sno: I meant it removes the standard enviornment file and replaces it with a custom verison Aug 06 15:35:01 that custom version doesn't consider the environment-setup.d files Aug 06 15:35:22 so we could add the environment-setup.d bits to buildtools ? Aug 06 15:35:23 but it should, didn't it? Aug 06 15:35:37 * sno is fundametally confused Aug 06 15:40:19 sno: To explain it I probably should just write the patch :/ Aug 06 15:40:21 RP: so your perl Storage is in what directory? Aug 06 15:40:36 JPEW: have it handy for rburton? Aug 06 15:41:08 If my machine wasn't doing a distro test build I'd make it build perl loads to see what happens Aug 06 15:41:12 RP: I'm sorry - I take a look then and check how it integrates and will do better next time Aug 06 15:45:55 sno: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=22af0add0f014fbe23516fbe8eaaf5540a342cf4 is what I think is approximately the right fix Aug 06 15:47:13 RP: thanks, I dig into it tomorrow morning as first task :) Aug 06 15:47:54 RP: I sent you an email, you can forward it to rburton Aug 06 15:48:44 Actually I'll resend to both of you... Aug 06 15:50:37 JPEW: thanks, requested access Aug 06 15:53:09 RP: Oh, sorry, I thought if you had the link it would just work Aug 06 15:53:19 rburton: /usr/lib64/perl5/5.30.2/Storable.pm vs /usr/lib64/perl5/5.30.2/x86_64-linux/Storable.pm Aug 06 15:55:25 RP: Ah, I had the wrong setting. It should work now so anyone with the link can download Aug 06 15:55:56 JPEW: thanks, got the files Aug 06 15:56:03 JPEW: meetings but will look in a bit Aug 06 16:02:59 RP: i wonder if its whether perl decides to make a .so alongside the .pm Aug 06 16:03:12 i get /aarch64/ and a .so too Aug 06 16:04:02 perl creates the .so for XS code, and the .pm is mostly the loader (if that was the question) Aug 06 16:04:44 and for Storable there is no pure-perl variant, if it doesn't create an .so, something went wrong Aug 06 16:06:19 so much for that theory then Aug 06 16:07:43 i'm having mad flashbacks in this Aug 06 16:35:05 rburton: we always see a .so, its a question of the path Aug 06 16:36:33 but surely the patch changing between builds wouldn;'t cause a problem in do_package_ipk Aug 06 16:37:22 rburton: it could as some data comes from do_package and some from do_packagedata Aug 06 16:37:45 rburton: I suspect that hashequiv combined to cause problems Aug 06 16:38:02 hashequiv works on the basis builds are reproducible **** BEGIN LOGGING AT Thu Aug 06 17:12:45 2020 Aug 06 17:14:57 hey guys, quick question - I'm trying to compile gstreamer1.0 with gstreamer1.0-gl but I'm having some issues - I've got DISTRO_FEATURES with opengl egl glx but when compiling plugins-bad I get gstreamer-gl-1.0 found NO. (Same error also in wpewebkit) Aug 06 17:15:20 compiling with mesa and )hopefully( v3d driver on rpi4 Aug 06 17:17:13 any ideas on what I've missed would be greatly appreciated :) Aug 06 20:39:46 Hi Everyone! Is anyone aware of an issue using SSTATE_MIRROR to build on a clean machine. I am currently trying to get all of my developers to point their SSTATE_MIRROR to a hosted location to greatly reduce their build time. When they do this a build error occurs: "Function failed: SYSTEMD_SERVICE_adsprpc value adsprpcd.service does not exist" Aug 06 20:39:57 This does not happen on a clean build with no SSTATE_MIRROR. Aug 06 20:41:28 sno: updated version with a commit message http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=faa419d5ee0a6f077b89577a7f99086e6de9be57 Aug 06 20:52:29 so I have a distribution based on poky thud, but need systemd v245 installed instead of v239. I have tried just bumping PV and SRCREV in a bbappend file, which fails because many of the 35 patches that Thud has need to be individually reviewed. Aug 06 20:54:32 more recently I've tried grabbing the systemd recipes from when systemd 245 was added to Poky, and modifying them to remove new features not available in Thud to get the package built. This has almost worked, but systemd-boot will not configure: Aug 06 20:54:55 ERROR: systemd-boot-245.5-r0 do_configure: meson failed [...] ERROR: Cross info file must have either host or a target machine. Aug 06 20:55:41 and that's fair, meson-sytemd-boot.cross has only these contents: Aug 06 20:56:12 [binaries] efi_cc = ['x86_64-poky-linux-gcc', '-m64', '-march=nehalem', '-mtune=generic', '-msse4.2', '-fstack- Aug 06 20:56:15 protector-strong', '-D_FORTIFY_SOURCE=2', '-Wformat', '-Wformat-security', '-Werror=format-security' Aug 06 20:56:33 , '--sysroot=[...]systemd-boot/2 Aug 06 20:56:33 45.5-r0/recipe-sysroot'] Aug 06 20:56:33 objcopy = 'x86_64-poky-linux-objcopy' Aug 06 20:56:56 is there some better way to do what I want here? Aug 06 21:12:08 Nooks: not really, those are the right approaches, you're just mixing software from different eras so some incompatibility is unfortunate but has to be worked out somehow Aug 06 21:16:51 RP: adding coreutils-native to DEPENDS (to get realpath) and removing the --cross-file argument from EXTRA_OEMESON seems to have done the trick, found by looking at the surprisingly small diff between systemd-boot_239.bb and _245.5.bb. Aug 06 21:17:09 I do realize this is basically certifiable Aug 06 21:24:15 Nooks: at least you realise that :) Aug 06 21:24:36 JPEW: strangely the Storable.pm in my build is now in the arch specific dir Aug 06 21:26:15 JPEW: I wonder if I inadvertently fixed this with the other change Aug 06 21:27:18 RP: yeah, for Reasons I have to use the GCC in Thud, perhaps more effort should have gone into using an old gcc on a newer Poky release. Aug 06 21:27:39 Nooks: oddly enough that might have been easier Aug 06 21:27:50 Nooks: hard to tell though Aug 06 21:45:53 RP: the comment no longer matches after uncommenting OECORE_NATIVE_SYSROOT, fyi Aug 06 21:46:05 (the above buildroot-tarball commit) Aug 06 21:48:59 kergoth: ah, yes, good point thanks Aug 06 21:49:05 np Aug 06 21:50:08 might be good to adjust the toolchain-scripts to handle host-only or target-only sdks generally based on the existence of the corresponding sysroots Aug 06 21:50:12 hm Aug 06 21:50:55 kergoth: that would be the logical next step, I just didn't want to get too deeply into this Aug 06 21:51:03 understandable Aug 06 21:51:34 * RP removes that comment block entirely Aug 06 21:51:54 kergoth: already gone from reviewing patch to fixing the problem :/ Aug 06 21:58:55 JPEW: I think I have my comment in the bug backwards, sorry :( **** BEGIN LOGGING AT Thu Aug 06 22:42:42 2020 **** BEGIN LOGGING AT Thu Aug 06 23:34:16 2020 Aug 07 00:11:11 hey there, im a bachelor student and currently im working with yocto, so im verry new in this topic. Everything worked fine and i even could compile FITimages without the rootfs but by simply adding INITRAMFS_IMAGE = "console-tdx-image" (toradex imx6ull som) i get 4 dependency loops. After a long try i managed to get rid of two of them by adding IMAGE_FSTYPES_remove = "tar.xz but i still have two left. Do someone know what Aug 07 00:11:11 possibly I can do to solve this problem? Aug 07 00:12:56 thank you in advance ;) Aug 07 01:06:30 Hi Aug 07 02:34:49 huh, BBTARGETS doesn't work well with multiconfigs. can't go 'bitbake mc:foo:' and have it run the targets defined there. admittedly probably nobody uses that variable, but.. :) **** ENDING LOGGING AT Fri Aug 07 02:59:57 2020