**** BEGIN LOGGING AT Fri Aug 07 02:59:57 2020 **** BEGIN LOGGING AT Fri Aug 07 03:51:12 2020 Aug 07 07:31:44 Hi! Where is explained how yocto Linux boots after loading the kernel? When yocto Linux boots I want to change the filesystem root to a mountpoint of an overlay filesystem. I found this Raspi script in the internet, but the approach how that script is called (entry in cmdline.txt in boot partition) seems to be quite different to how yocto boots. Aug 07 07:32:08 http://wiki.psuter.ch/doku.php?id=solve_raspbian_sd_card_corruption_issues_with_read-only_mounted_root_partition Aug 07 07:33:31 fbre: there is no documentation on this because it is board specific, not yocto specific. it depends on the bootloader in use, and the mechanisms it applies. Aug 07 07:37:27 I use u-boot which loads and starts the kernel. But that script I want to add (see my link above) uses stuff which requires a loaded kernel already. That's why I think it's already all about mechanisms already within Linux and the distro concepts. Aug 07 07:41:43 fbre: the cmdline.txt part is absolutely rpi specific. agreed on that the script runs in userland but it again is pretty rpi specific Aug 07 07:42:28 fbre: i know that it is a recurring topic these days to have a ro-rootfs + overlay, but so far nobody has shared an approach to refer to. Aug 07 07:57:06 I just wonder what actually happens in the time between the Linux kernel starts up and the time of /etc/fstab is read. Which scripts are running, where are they located? Some say there is /etc/inittab but I can't find such file in yocto Linux. I think I need to understand that boot stage at first before I try to hook a script somewhere... Aug 07 07:57:52 init is run. and depending on which init you have, this decides what gets run in which order. Aug 07 07:58:52 I just can see /sbin/init which is a binary. What does /sbin/init do? Aug 07 08:00:21 It's a link to /lib/systemd/systemd Aug 07 08:00:29 RP: when I understand your proposal correctly, it bundles both my suggestions in one commit again (as the initial proposal with a bad commit messages was). Aug 07 08:00:48 I give it a shot and tell you how it behaves Aug 07 08:02:00 fbre: so then systemd is run and works through its units as specified. and i am very sure that there is one or more units that do the mounting. Aug 07 08:02:37 fbre: see: https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html Aug 07 08:05:05 LetoThe2nd: cool, thanx! That's a good trace to further follow up to :] Aug 07 08:23:32 Hello Everyone, I created a qemux86 iso image from Yocto Zeus, and I am able to boot into the system in VBox. A problem that I am facing now is that / is mounted on /dev/loop0 as ro, but I need to change settings e.g. sshd_config. Sorry maybe for noob question, but is there possibility of mounting the system in rw mode? I tried editing the cmd_line adding rw on root=/dev/ram but no success. Thanks a lot in Aug 07 08:23:38 advance for your kind attention Aug 07 08:27:41 f843d0: iso images are probably ro by default, as they are supposed to end up on ro media... Aug 07 08:28:12 f843d0: so my guess is that iso is just not the image type that you actually want. Aug 07 08:28:54 LetoThe2nd: thanks, so for example for importing the solution in VBox, should I go for vmdk somehow? Aug 07 08:30:11 f843d0: why "somehow"? Aug 07 08:30:13 f843d0: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n287 Aug 07 08:30:23 and why zeus? :P Aug 07 08:30:58 LetoThe2nd: is the stable, ain't it?! :) Aug 07 08:31:08 f843d0: um, no? Aug 07 08:31:23 https://www.yoctoproject.org/ Aug 07 08:31:34 LetoThe2nd: https://wiki.yoctoproject.org/wiki/Releases Aug 07 08:32:12 f843d0: ok, and what is saying that zeus is the latest stable there? Aug 07 08:32:38 LetoThe2nd: Zeus 3.0 October 2019 3.0.3 Stable 22.0.3 1.44 Aug 07 08:33:09 Dunfell 3.1 April 2020 3.1.1 Long Term Stable Aug 07 08:33:30 :) Aug 07 08:34:08 fbre: Have you looked at https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-image? I'm using raspberry pi + read-only-rootfs, and it works well. Aug 07 08:34:33 erbo: its about the overlayfs magic (again) Aug 07 08:36:37 Ok, I figured the interest in that was in order to find a way to achieve what the magic already achieves. :) Aug 07 08:36:54 erbo: I opened your link and searched for "overlay" but there aint no such phrase Aug 07 08:38:08 fbre: the read-only-rootfs image feature will result in overlays being used, but the documentation mostly talks about the end result and doesn't go into details of how it's achieved (which is partyly using overlays) Aug 07 08:38:49 erbo: really? (/me is not so sure about that, but would love to be proven wrong) Aug 07 08:39:08 On my rpi image built with read-only-rootfs, I have overlays for /var/spool/, /var/cache and /var/lib Aug 07 08:40:28 erbo: really overlays, or rather just tmpfs mounts? Aug 07 08:40:48 mount shows e.g. "overlay on /home/root type overlay (rw,relatime,lowerdir=/home/root,upperdir=/var/volatile/root,workdir=/var/volatile/.root-work)" Aug 07 08:40:59 erbo: My idea is to support a factory reset which throws all done system updates over board Aug 07 08:41:04 that's an extra overlay I added for convenience Aug 07 08:41:34 erbo: therefore everything coming from an update must be in the upper overlay filesystem. Aug 07 08:41:40 erbo: did you add that, or does meta-raspberrypi bring that? Aug 07 08:41:48 fbre: ah, so you want changes to be persistent, but in an overlay so it can be reset? Aug 07 08:42:18 LetoThe2nd: I just added the /home/root overlay, the other stuff is out-of-the-box Aug 07 08:42:42 erbo: yes, in the end I will have 2 partitions, one for each layer. The lower layer is read-only, the upper layer is read-write. The factory reset just removes the upper layer. Aug 07 08:43:07 LetoThe2nd: the volatile binds are provided by poky/meta/recipes-core/volatile-binds/volatile-binds.bb Aug 07 08:43:39 erbo: yup, but every incarntion i've seen so far just goes for tmpfs. Aug 07 08:44:16 The use case so to speak is simply to support an easy total factory reset. Aug 07 08:45:02 LetoThe2nd: yes, it use a tmpfs in /var/volatile/ and then use overlays to put parts of the filesystem there. Aug 07 08:45:34 I think it's not enough to have overlays in a few subdirs Aug 07 08:45:55 fbre: If you look at the volatile-binds receipe, you can probably get some ideas of how you can instead achieve an overlay for the whole root Aug 07 08:46:22 erbo: ok, thanx! Aug 07 08:46:30 tmpfs with a persistent partition is the most common way I've seen to support factory reset. That and a 'recovery' partition to overwrite the primary, which IMHO is daft because wear levelling Aug 07 08:47:04 Morning all, btw Aug 07 08:49:40 moinmoin :) Aug 07 08:50:20 LetoThe2nd: thanks, I've created wic.vmdk and everything looks fine :) Aug 07 08:50:30 f843d0: :) Aug 07 09:36:00 https://superuser.com/questions/1507278/mount-overlayfs-on-before-systemd-starts is talking about an initramfs /init file. The other user found it in buildroot_directory/fs/cpio. Is there something similar in yocto? Aug 07 09:37:11 https://developer.toradex.com/knowledge-base/initramfs-and-tmpfs Aug 07 09:37:13 They write it is a script, the right place to inject the using of an overlay filesystem Aug 07 09:38:47 escalion: (y) Aug 07 09:40:13 tldr; you can find it in oe-core. If you are using poky you will need to check the conf to check which initramfs image it builds Aug 07 09:40:28 :) Aug 07 09:41:09 remember you can use a bbappend to add files to a package Aug 07 09:42:42 fighting a battle myself at the moment. can't get me head around how to make gstreamer1.0-gl to build from https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-multimedia/gstreamer?h=dunfell Aug 07 09:48:56 escalion: Can you tell me the path to oe-core in the yocto/sources dir? Aug 07 09:50:05 escalion: Do you mean yocto/sources/meta-openembedded/meta-oe/recipes-core? Aug 07 09:51:36 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/core-image-minimal-initramfs.bb?h=dunfell Aug 07 09:51:46 poky uses this one Aug 07 09:58:54 found the answer to my issue, needed to add wayland to distro_features Aug 07 09:59:05 Something so simple yet crippling xD Aug 07 09:59:44 fbre, did that help btw? Aug 07 09:59:58 or was there something more specific you was trying to achieve? Aug 07 10:02:45 escalion: I've been looking into all those files int poky/recipes-core/images at the moment. But it seems I don't find anything which has to do with a script called by initramfs init process. Aug 07 10:03:54 escalion: you know, I'm looking for a script which mounts the root filesystem. I want to change it to mount an overlay fs instead Aug 07 10:04:54 I suspect it is somewhere in the corner of files where yocto defines the initramfs init stuff Aug 07 10:05:50 you mean here? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initscripts/initscripts-1.0?h=dunfell Aug 07 10:08:31 escalion: yeah, I get the feeling I'm getting closer to it Aug 07 10:09:39 It's all very complicated and I'm drowning in the flood of scripts Aug 07 10:15:47 break it down, its not as complicated as it looks Aug 07 10:18:54 sno: FWIW that patch I hacked up broke all the esdks in automated testing so its not quite right Aug 07 10:25:08 What is the master script of those initrdscripts? I don't get it. Script mountall.sh looks promising but too hard to understand its content Aug 07 10:26:38 RP: my test still in progress but looks good so far Aug 07 10:28:04 fbre: its an init script so its installed by updated-rc.d and run through the init system Aug 07 10:30:53 Is it poky/meta/recipes-core/initrdscripts/initramfs-framework/init ? Aug 07 10:32:30 fbre: more likely the main image init system would call mountall.sh Aug 07 10:32:45 fbre: you have two images and two init systems, first the initramfs , then the main image Aug 07 11:10:36 fbre: you can add an overlay at the mountall.sh point however. Just add the declarations after line 20. Unless you need the overlay to be available in the initramfs Aug 07 11:11:20 you could also use rc system to add overlay Aug 07 11:13:32 OK, friends. Time to go home for today, thank you all very much for your hints, and have a nice weekend! **** BEGIN LOGGING AT Fri Aug 07 11:21:14 2020 Aug 07 11:38:45 does yocto support libssl ? Aug 07 11:40:48 gaston53: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb?h=master Aug 07 11:42:13 PaowZ so openssl recipe will add libssl package Aug 07 11:42:35 gaston53: yes Aug 07 11:43:28 qschulz just a question, can I only add libssl package without any other packages related to openssl ? Aug 07 11:44:13 RP: seems because of your patch modifies OECORE_NATIVE_SYSROOT which is originally set by toolchain-scripts.bbclass Aug 07 11:45:09 gaston53: if a package depends on another package, it'll be pulled in anyway Aug 07 11:45:34 gaston53: so add libssl package and see what's added, maybe that's good enough. If not, either mistake in the recipe or something to tinker with Aug 07 11:46:11 qschulz okey thanks Aug 07 11:50:03 sno: so it has the wrong value? Aug 07 11:50:13 * sno nods Aug 07 11:50:57 Maybe that is the conflict I dicovered - I don't really understand the entire ecosystem yet Aug 07 12:02:54 sno: I've tried another tweak in master-next Aug 07 12:03:09 Is there a way to disable the usage of bsp's *.scc files? What I would love to have is just my custom defconfig with some custom kernel fragments. Is this possible with linux-yocto-rt or do I need to create a fully custom linux-kernel recipe? Aug 07 12:03:42 malrak: you should just be able to override the bsp Aug 07 12:05:29 You mean by e.g. not using core2-32-common.inc? Aug 07 12:05:35 RP: You mean by e.g. not using core2-32-common.inc? Aug 07 12:11:49 malrak: I don't know. You can usually override pretty much any setting Aug 07 12:15:30 RP: so my main problem is as follows, merge_config.sh accepts my defconfig *and* my config fragments, *however* if i check the configs-variable used in ~do_kernel_configme~ it has loads of additional configurations added from all kinds of sources Aug 07 12:19:21 RP: https://github.com/rehsack/poky/commit/50ce74ed49a426e0e035632b9bc837f3f8b45864 is probably not that wrong Aug 07 12:20:13 malrak: I think it should only touch fragments its told to. zeddii probably can point more specifically if/as/when he's around Aug 07 12:20:50 RP: and the openssl / buildtools-tarball is a seond approach Aug 07 12:21:12 sno: its isn't correct. buildtools just overwrites that Aug 07 12:21:32 RP: yes, the openssl parts Aug 07 12:21:55 sno: no, it replaces the entire environment script Aug 07 12:22:34 RP: but when layers add stuff into ${D}${SDKPATHNATIVE}/... - they are kept Aug 07 12:22:43 I see the files :D Aug 07 12:23:12 sdk$ ls -l buildtools/sysroots/x86_64-pokysdk-linux/environment-setup.d/ Aug 07 12:23:12 total 8 Aug 07 12:23:12 -rw-r--r-- 1 sno sno 73 Aug 7 13:07 openssl.sh Aug 07 12:23:12 -rw-r--r-- 1 sno sno 229 Aug 7 13:07 sds.sh Aug 07 12:26:29 sno: I mean the top level environment script you add that code to is not included in buildtools tarball. Therefore when you remove these things from buildtools-tarball, it breaks Aug 07 12:28:27 RP: yes, that is true and was done to show up the conflict between the ${SDKPATHNATIVE}/environment-setup.d/*.sh and buildtools/environment-setup Aug 07 12:29:01 RP: I have no sane idea to fix that and I don't knwo why there're incompatible information Aug 07 12:31:23 sno: I *cannot* accept patches that break things Aug 07 12:31:28 RP: I also see that cmake-nativesdk installs into a different path than openssl-nativesdk Aug 07 12:31:40 RP: agreed - you should not :D Aug 07 12:32:01 RP: I sent it to have a basement to discuss which of both (existing) ways is wrong Aug 07 12:32:32 RP: and maybe you now see why https://github.com/rehsack/poky/commit/50ce74ed49a426e0e035632b9bc837f3f8b45864 cannot use OECORE_NATIVE_SYSROOT Aug 07 12:33:30 sno: quite frankly, no :/ Aug 07 12:34:24 sno: I'm doing my best to try and untangle this but I still don't understand what exactly you're really trying to fix. I am frustrated you're pushed to have patches merged which fix your use case but as known to break other things Aug 07 12:35:19 RP: that's not my intention - apologies for this Aug 07 12:43:26 RP: I try to explain better ... give me a few minutes (I try to figure out what is the right way) Aug 07 12:43:27 RP: cmake installs nativesdk related files into ${SDKPATHNATIVE}/environment-setup.d via https://github.com/rehsack/poky/blob/master/meta/recipes-devtools/cmake/cmake_3.17.3.bb#L39-L45 Aug 07 12:43:27 RP: cmake-native install into ${D}${base_prefix}/environment-setup.d/cmake.sh via https://github.com/rehsack/poky/blob/master/meta/recipes-devtools/cmake/cmake-native_3.17.3.bb#L48 Aug 07 12:43:27 RP: openssl-nativesdk does it similar to cmake-nativesdk -- but only the one of cmake-native is included in the script generated by toolchain-scripts.bbclass Aug 07 12:43:28 RP: all I want is to understand how it is meant to add files to sdk to configure for local enhancements Aug 07 12:44:03 RP: So please apologize the patches felt being pushed (harder) - that wasn't intentional Aug 07 12:47:05 sno: I don't really understand why we'd have a cmake-native environment-setup.d :( Aug 07 12:47:45 RP: precisely - me neither Aug 07 12:48:15 RP: I understand that the patch breaks things and I'm interested in fixing it - not getting it pushed Aug 07 12:48:21 sno: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b92717ae485dcde5aa0f477d1e5fcc3205ed7a23 Aug 07 12:49:51 sno: which SDKMACHINE are you using? Aug 07 12:50:50 RP: unfortunately this doesn't explain why only `$OECORE_TARGET_SYSROOT/environment-setup.d/*.sh` and `$OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh` are sourced but not those which are installed in ${SDKPATHNATIVE}/environment-setup.d Aug 07 12:52:36 RP: SDKMACHINE=x86_64 Aug 07 12:53:06 RP: I think I found my error. I had SRC_URI += and not SRC_URI_append. Now with SRC_URI_append it only pulls in my configs Aug 07 13:06:21 RP: is my confusion a bit clearer to you? Aug 07 13:08:34 sno: yes, a little. I think we perhaps start by deleting the cmake-native sdk bits... Aug 07 13:08:49 RP: :D Aug 07 13:10:13 RP: all I'm trying to figure out is: where do I have to add enhancements to get them used by eSDK - and it seems it's `${D}${base_prefix}/environment-setup.d/` - and maybe in a later stage openssl-nativesdk sould be fixed, too Aug 07 13:12:39 sno: so you're trying to use this in the eSDK? Aug 07 13:13:52 RP: yes, I'm trying to use this in eSDK Aug 07 13:14:41 RP: to be more clear - I'm trying to add a script which exports a new shell variable which easy allows doing developer builds using the eSDK and later using devtool for integration steps Aug 07 13:15:18 sno: so there is something wrong with the eSDK environment. I then wonder why all the eSDK tests pass :/ Aug 07 13:16:24 RP: maybe it's not used much ¯\_(ツ)_/¯ Aug 07 13:16:37 RP: it was very difficult to find examples :) Aug 07 13:18:03 sno: but we do have tests which we run regularly Aug 07 13:18:26 RP: but what do they expose into the environment-setup.d/*.sh ? Aug 07 13:18:43 it's only that - everything else seems to be very sane Aug 07 13:18:49 so it suggests we have a gap in the testing. I'd be a lot happier if I could show problems in the tests Aug 07 13:19:18 RP: I fully agree - but I do not understand the issue enough to create a sane test for that Aug 07 13:28:26 RP: is there someone else beside you who can ''guide'' me to create such a test? moto-timo maybe? Aug 07 13:40:02 sno: esdk experts are bluelightning and myself. A few people could probably help with sdk tests but I don't know who if anyone has time Aug 07 13:45:37 RP: when you know that someone has a tuit, please remind this issue Aug 07 13:46:48 sno: I am looking at it locally a little more Aug 07 13:46:58 RP: thanks Aug 07 14:03:45 Hello Everyone, I was able to set the IMAGE_ROOTFS_SIZE to control /. But for /boot, currently I manually modified poky/scripts/lib/wic/canned-wks/common.wks.inc adding --size to the part directive. Is there a more elegant way to achieve this, maybe via some other *.conf directive? Aug 07 14:19:51 sno: I do now understand what you mean about all this. I am however struggling to see the correct way to fix it Aug 07 14:41:34 RP: no worries - that's all I wanted to reach at the first step and still apologizing for how I did it Aug 07 14:47:35 sno: np. The issue is that we're mixing native and nativesdk recipes and they don't look to co-exist well. I don't really want people to have to write relocation code twice Aug 07 15:05:53 sno: basically my conclusion is you may need to add environment-setup to -natives for eSDK and to -nativesdk for SDK Aug 07 15:06:27 The code is sourcing the right things but buildtools does need improving to use these scripts in a way which doesn't break eSDK Aug 07 15:09:43 RP: I give it a try and will report Aug 07 15:18:13 sno: I've written up a summary of what I found and sent to the list Aug 07 15:18:33 RP: cool, thanks Aug 07 16:05:04 huh, that's not great.. found an archiver issue. it disables inclusion of the gcc recipes in favor of gcc-source, which is great for the source, but means that ARCHIVER_MODE[dumpdata] and ARCHIVER_MODE[recipe] don't actually work for the gcc recipes. only the gcc-source recipe/data is emitted Aug 07 16:06:17 thats fine if you're only emitting the data for info on source construction, but not if you're trying to comply with emission of 'build instructions' Aug 07 16:07:49 not sure if i need to do that anyway, but it's a clear bug. i'll open an issue Aug 07 16:08:15 also looks like libtool-cross and qemuwrapper-cross don't actually inherit cross, so aren't excluded by removing cross from COPYLEFT_RECIPE_TYPES Aug 07 16:09:14 kergoth: cross doesn't actually work for anything not gnu :( Aug 07 16:09:25 kergoth: it really should be called cross-gnu or something Aug 07 16:11:30 ah, do other buildsystems expect CC, etc to correspond to the target, not build machine in a cross configuration, and rely on BUILD_ or _FOR_CROSS style build machine tooling variables? Aug 07 16:11:53 makes sense Aug 07 16:12:45 if that's the case it'd probably be worth splitting the class up. rename the autotools-specific portion and retain a common core Aug 07 16:43:18 What is the best way to install a "-dev" package into an image? I know that IMAGE_INSTALL+= " somepackage-dev" might not be allowed according to the documentation. Basically, I want a developer package to be added to my system image so that I can build and test software linking a specific library on a device. Aug 07 16:48:03 kergoth: I don't remember the issue, I know I found it much safer to not use it for anything that wasn't binutils/gcc/gdb Aug 07 17:43:07 i need to use a native objcopy as part of the commands used to create my own image type Aug 07 17:43:13 objcopy comes from binutils Aug 07 17:43:48 but the binutils recipe explicitly deletes the ${bindir} when doing a do_install_class-native Aug 07 17:44:07 tlwoerner: those are assumed to come from the host Aug 07 17:44:20 although perhaps little uses objcopy Aug 07 17:44:29 RP: oh, okay. sounds good Aug 07 17:44:53 tlwoerner: binutils-native is mainly for libbfd-native Aug 07 17:47:41 sno: I think I have a patch which at least might improve some of this mess... Aug 07 18:01:31 in my custom image bbclass, is there no easy way to add my artifact to the list of files that are removed during do_clean? Aug 07 18:02:06 there is: do_image_[cleandirs] but no do_image_[cleanfile] Aug 07 18:03:06 i guess i'll just do a do_clean_append(){}? Aug 07 18:05:47 tlwoerner: shouldn't you be installing it via the deploydir mechanism and hence it could be autocleaned? Aug 07 18:07:58 RP: ah, so no manipulating files in ${DEPLOY_DIR_IMAGE} directly then? ;-) Aug 07 18:08:12 tlwoerner: not recommended Aug 07 18:11:42 RP: cool Aug 07 18:12:52 RP: hmm, the IMAGEDEPLOYDIR doesn't include the kernel, which i need for my custom blob, but i can get that from ${DEPLOY_DIR_IMAGE} i guess Aug 07 18:13:37 tlwoerner: its fine to consume from DEPLOY_DIR_IMAGE, just don't write to it Aug 07 18:14:19 RP: perfect! thanks :-) Aug 07 18:24:13 RP: Ah, OK. That explaination of the perl bug makes more sense. It's also easier to test for :) Aug 07 18:24:32 JPEW: sorry about the confusion! Aug 07 18:24:55 RP: No problem; did you have a build where it was in the non-arch directory? Aug 07 18:25:06 aha. nice, my .config analysis enhancement is already getting me fixup patches :D Aug 07 18:25:13 JPEW: no, that is the build I've never found :/ Aug 07 18:25:23 RP: Got it Aug 07 18:42:18 Im adding a patch to a bitbake recipe for the kernel, the patch fails to apply and then every subsequent build bitbake says it founds a fence post and is continuing after my patch. How can I force it to actually try and apply the patch each time? Aug 07 18:42:29 Or at least clean everything all the way so that it will attempt it again. Aug 07 18:43:00 I have tried a complete clean and rebuild and it does not help, the only thing that will let me retry is if i clone the whole repo, make changes and restart the build. This is quite time consuming. Aug 07 18:43:21 fence post ? you are on a really old release then. I abandoned that code due to complexity. Aug 07 18:43:58 It is a build that i received from a vendor for their parts. It is based on thud Aug 07 18:44:36 Latest patch was Feb 26 2019 ship /etc/drirc in mesa-megadriver Aug 07 18:46:20 Is there a way to clear these "fence posts"? a folder or file that is stored somewhere? Aug 07 18:46:49 it's in the kernel source's .git directory, but even though I wrote all that code, I'd have to go look up exactly what it is. Aug 07 18:47:41 actually, if it is looking for fence posts. It should be thud. I just checked and had already removed htat. Aug 07 18:47:54 s/should/shouldn't/ Aug 07 18:48:42 Whats a good way to check exactly which build / rev I'm using? Aug 07 18:49:55 sec. I'm checking. I see some remnant code. so it could be thud. there were some transition releases. but they all blur together. Aug 07 18:50:21 any hints on removing the dependency from do_populate_sysroot tasks to do_install_ptest_base? If I modify a ptest in recipe A and recipe B depends on A, I think recipe B do_compile gets executed because of this dependency. Concrete example is between qtbase and systemd, so triggering a qtbase build is annoying ;p Aug 07 18:53:32 yah. wow. that's some transition code that I didn't even write. It is checking the name of your patch and comparing it to the internal patch series. if there's a match, it takes that as the fence post. Aug 07 18:54:08 Hrmm, its strange because it seems to set that post even if the patching fails. Aug 07 18:57:03 Do you have any suggestions on a good candidate to rebase to? I wouldn't mind trying to upgrade this to a proper stable release (I'm having all sorts of SSTATE_CACHE issues as well which i believe are fixed in newer releases). Aug 07 18:57:38 dunfell (the latest release), is a good candidate. since it is LTS as well. Aug 07 18:58:00 Jebee: I don't suppose the layers / kernel for this are public ? I could run a couple of quick tests if they were. Aug 07 18:59:52 or pastebin the error message and I can look for more details. Aug 07 19:00:11 @zeddii unfortunately it isnt... and its a complete mess, this particular vendor has completely mangled this entire code base. I tried to rebase it just to the latest release of thud and that cause a ton of issues. Aug 07 19:00:34 I'm trying the rebuild currently. I'll pastebin the error as soon as I can get it to come up again. Aug 07 19:00:56 cool. I can very likely get you moving. I'll just have to swap some things back into my memory :D Aug 07 19:08:00 ha, even deleting the whole kernel folder and did a repo sync again, and it still skipped it due to the fence post being found. Aug 07 19:08:02 https://pastebin.com/iPb7hYMX Aug 07 19:18:26 detached head ? ouch. they are doing strange things. Aug 07 19:19:38 if you can locate your kernel source directory for the build (build/tmp/work-shared/$MACHINE/kernel-source (at least, that's where it is now, I can't remember if we had work-shared in thud, but we should have). Aug 07 19:19:46 then look in the .git/ directory Aug 07 19:27:28 So the .git directory is there. Aug 07 19:28:10 is kgit-s2q.last there ? it pretty much has to be, since that is what dumps the message you are seeing. Aug 07 19:29:11 Here is a pastebin of when patch actually fails. Aug 07 19:29:14 https://pastebin.com/1nBh5pZq Aug 07 19:30:25 so the patch isn't right for that kernel. but that isn't one of your patches from the SRC_URI ? Aug 07 19:31:53 that is a patch that i need to include for the kernel being built, Ive created a recipe with a bbappend file that has a SRC_URI append, and a FILESEXTRAPATHS_prepend. Aug 07 19:32:22 ok, cool, but it isn't valid for where it is being applied, so you need to fixup the patch itself. Aug 07 19:33:03 Right, I was thinking of modifying the source directory in the do_patch_prepend, and then setting it back in the do_patch_append. Aug 07 19:33:11 would that work, without having to touch the patch? Aug 07 19:33:38 you've got some bad paths in the patch, for the actual files being patched: Aug 07 19:33:40 build/tmp-glibc/work-shared/wnc/kernel-source/ Aug 07 19:33:54 that shouldn't be there, if its in the patch. Aug 07 19:34:20 doing a dance with the source directory, I'm not so sure it'd work out. Aug 07 19:37:21 so the way the vendor delivered this patch is that they just took a diff of the whole folder that is ../ from poky, which includes many module diffs. (seems like a terrible way to send a patch for a system like this)