08:58 <JaMa> RP: we need the .pc to pop the patches from WORKDIR, but now I'm thinking about removing ${S}/patches in the QuiltTree.Clean (where we were already removing the series file), that feels like better place anyway

09:00 <JaMa> will send patch after the weekend, now some family business to take care of

09:54 <RP> JaMa: family should come first, it can wait for next week

10:35 <Patrick2> Hi, its me again. Iam the guy who is facing issues with the original U-Boot SPL with Yocto and meta-ti . I already know that some debian image is booting, the "U-Boot SPL 2018.09-00001-ge10814359b (Sep 10 2018 - 19:52:59 -0500)" is in there. I tried to build several branches from ti-U-Boot none of them booted.  So the main question here is, does

10:35 <Patrick2> someone know if an Altera USB Blaster will work as a JTAG debugger?

10:37 <Patrick2> Obciously iam not able to find the sources of this 2018.09 build, i think it must be patched somehow

10:43 <Patrick2> I just found https://elinux.org/BeagleBoardJTAG#TinCanTools_Flyswatter . So now i know which ones definetly work with my BB. I would still be interested in suggestions which of these are known to be very versatile. I am planning other projects with Broadcom processors

19:02 <derRichard> RP: well, name_to_handle_at() will give you a opaque file handle object for a file. it is reboot consistent. the handle is a building block for user space file servers such as nfs.

19:03 <derRichard> the inode alone will be resued a lot. that why we have file handles, usually they are inode plus inode-generation

19:04 <derRichard> the downside of these filehandles is that they are not plain integers

19:44 <RP> derRichard: 128 byte strings per file which would be "fun" with the database

19:45 <RP> derRichard: it is probably worth exploring although our inode reuse issues don't seem as prevalent now

19:46 <derRichard> RP: sure. but maybe we can store the fhandle together with the inode and use it only when we want to make sure whether a inode has changed or not

19:47 <RP> derRichard: I didn't know the fhandles existed so yes, worthy of further thought

19:48 <derRichard> no need to worry. i'm also a maintainer with way to little time ;-\

19:49 <derRichard> in the next weeks i'll try to figure why i see so many pseudo aborts in m ci/cd pipeline. something is wonky there

19:50 <RP> derRichard: you're seeing a lot of aborts? :/ Docker?

19:50 <derRichard> first i thought i suffer from this bug: https://chrisdown.name/2021/07/02/tmpfs-inode-corruption-introducing-inode64.html

19:50 <derRichard> RP: yes, i see 1-2 aborts per week. and yes. every build happens in docker

19:52 <derRichard> but now all builds happen on ext4. so it can't be a tmpfs bug. maybe some overlayfs (or docker) wtf....

19:52 <RP> derRichard: there are known issues with overlayfs, docker and pseudo

19:53 <derRichard> oh. do you have a pointer for me?

19:53 <derRichard> actually we do *everything* yocto related in docker to have a well defined and stable base.

19:54 <RP> derRichard: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13923 maybe but I seem to remember JPEW does something in pyrex to avoid this

19:55 <derRichard> thanks a lot! i'll dig into this

19:56 <RP> derRichard: going from memory, overlayfs has a habit of changing the inode numbers under us so the pseudo database gets corrupted as the numbering changes

19:57 <RP> derRichard: we probably could have some way of having pseudo sync it's state with the inodes on disk when it loads, or at least check them but that has been a time issue

19:58 <derRichard> sounds plausible. since overlayfs implements exportfs, name_to_handle_at() will help here too :-D