**** BEGIN LOGGING AT Thu Jan 14 02:59:57 2021 Jan 14 03:10:36 paulg: there's a plan to set up a "next" branch in AGL to track poky master while AGL master stays on dunfell, I suspect there's a couple of platforms with BSP layers where we'd see the issue Jan 14 03:12:38 paulg: but we might end up just testing with qemu* for the interim, it's not clear to me yet Jan 14 03:15:25 I tested it on v5.4 to ensure it fixes the issue there; once I test on v5.8+ to ensure it doesn't somehow break things there, I'll probably just send it along. Jan 14 03:15:58 At least that way, anyone impacted can (in theory) find it via google w/o rewriting their own fix. Jan 14 04:02:58 as much as I like the ability to manage all my mailing lists via gmail. Dear lord the threading is so broken it is shocking. Jan 14 04:08:23 that and the random lkml mails that get tossed in spam for no apparent reason. Jan 14 04:09:09 the only way to dig replied patches, or v2, etc out of the threads, is to use imap and mutt Jan 14 04:09:40 which is ok, since I don't mind that, but I occasionally miss that there's a new version completely. Jan 14 04:09:56 (yes, I know there are tools that can help with this) Jan 14 04:13:38 various kernel people are using this "b4" thing which I've never really looked into yet. Smells like an interface to lore.kernel.org Jan 14 04:13:49 https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation Jan 14 04:14:01 yah. I remember reading some thread about greg claiming it was the cat's ass Jan 14 04:14:48 I should try it, since really, just that intro is what I end up doing with sorting in mutt, etc. Jan 14 04:14:51 I don't merge dumptruck loads of poo from other people, so it probably isn't for me. Jan 14 04:15:23 i don't have that much volume either, but if I let things soak on the list for more than a couple days, things get tied into knots quickly Jan 14 04:15:56 but the msg-id thing is the problem. I wonder if it can be adapted to non-lore use cases Jan 14 04:16:31 NFI, but probably warrants a casual drive-by snoop to see. Jan 14 04:17:15 yup. I'll put it on my "I can't believe covid arrest has made me so desperate to look into this" list. Jan 14 04:17:25 I would hope it would work on any standard mbox input, given that is what lore wants to hand out. Jan 14 04:17:56 heh. CDS - Covid defeat syndrome. Jan 14 04:18:47 I powered up an old beagleboard-xM ; pretty sure I can chalk that up to CDS. Jan 14 04:20:08 yup. I put linux on my 2008 macbook, so I could run home automation on it. that's my low bar so far. Jan 14 04:21:43 CDS -- Covid Desparation Syndrome. Sounds better than "defeat". Jan 14 04:23:10 yah, but kind of like how novel coronavrus sars v causes covid, it should be that IPI-2k2 causes it. Jan 14 04:23:51 (incompetent politician infection 202x) Jan 14 04:26:07 I mucked with dd-wrt on some ancient router e-waste semi-recently ; that was also 100% due to CDS. Jan 14 04:29:56 I wonder what that says about the fact that I touched systemd code for the 1st time ever today? Jan 14 04:30:07 that's probably lower Jan 14 04:30:23 Somebody pass me the bleach and steel wool. Jan 14 04:30:53 Need to see if I can get that stink off me. Jan 14 04:31:24 heh. my plan is to stand up now and watch netflix, if there's anything I haven't seen yet :D Jan 14 04:31:59 Bridges of Madison County is still there waiting for you. Jan 14 09:45:33 I've put a patch and a .bbappend in a custom layer, but bitbake doesn't find the patch, he looks for it only in the original layer, how can I fix that? Jan 14 09:47:55 Sponge5: first of all tect with bitbake-layers show-overlayed Jan 14 09:48:21 sounds like a naming issue.... i put bbappends in custom-layers all the time Jan 14 09:49:05 I might be missing something in layer.conf? Jan 14 09:49:14 mckoan: what am I looking for with that command? Jan 14 09:49:28 mckoan: my .bbappend? Jan 14 09:49:34 Sponge5: maybe FILESEXTRAPATHS_prepend := "${THISDIR}/files:" in the bbappend? Jan 14 09:49:47 Sponge5: you should see that bbappend is taken into account Jan 14 09:50:11 mcfrisk: that's the second frequent mistake Jan 14 09:50:47 Sponge5: pastebin-ing the bbappend would help a lot Jan 14 09:50:59 mcfrisk: done that, except with ${PN} Jan 14 09:51:56 https://pastebin.com/4S4FG8JR Jan 14 09:52:59 BBPATH .= ":${LAYERDIR}" and BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend" Jan 14 09:53:01 whats the name of thefile for the .bbappend Jan 14 09:53:02 are in my layer.dir Jan 14 09:53:33 OutBackDingo: nss_3.51.1 Jan 14 09:53:38 OutBackDingo: nss_3.51.1.bbappend Jan 14 09:54:38 OutBackDingo: it matches nss_3.51.1.bb Jan 14 09:55:14 mmmm or nss_3.51.%.bbappend Jan 14 09:55:58 bitbake finds the bbappend, it doesn't see the patch that's in the same directory as the bbappend Jan 14 09:55:58 Sponge5: can you see it with bitbake-layers show-appends ? Jan 14 09:56:04 mckoan: no Jan 14 09:56:25 so it doesn't see the bbappend? :D Jan 14 09:56:35 Sponge5: therefore bitbake doesn't find the bbappend Jan 14 09:56:46 bitbake-layers show-appends Jan 14 09:57:00 then why would it try to build nss-native-3.51.1-r0.rpipatch1 Jan 14 09:57:53 we need more details Jan 14 09:58:42 Could you give me a resource for creating layers? I followed https://training.ti.com/customizing-yocto-for-production-modifying-recipes and it doesn't work for me Jan 14 09:59:15 if bitbake -e output doesn't show the bbappend file, then layer config isn't correct. if it does, something else is wrong. Jan 14 10:01:16 mcfrisk: It doesn't Jan 14 10:06:45 Sponge5: bitbake-layers create-layer Jan 14 10:07:32 https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#creating-a-general-layer-using-the-bitbake-layers-script Jan 14 10:12:52 is there some undocumented changes to ptest? I have ptest in DISTRO_FEATURES_append and ptest-pkgs in EXTRA_IMAGE_FEATURES, and my recipes inherit ptest, but ptest packages are not build. All this worked in Thud but now not in Dunfell Jan 14 10:13:37 No, should work still Jan 14 10:13:42 trying to bitbake a my-recipe-ptest package gives nothing RPROVIDES error Jan 14 10:13:49 right, you build recipes, not packages Jan 14 10:13:55 so bitbake my-recipe Jan 14 10:15:13 I mean having IMAGE_INSTALL += "my-package-ptest" like wiki suggests, does not work anymore Jan 14 10:15:53 and having ptest-pkgs in image features to build all ptest-enabled packages does not build anything Jan 14 10:15:57 i'd check that the distro features change is actually working, bitbake -e my-package|grep DISTRO_FEATURES= Jan 14 10:16:32 @stuoam1: ptest packages should even be built by default. they should be in DISTRO_FEATURES, as rburton points out Jan 14 10:16:47 well, depends on your distro setup Jan 14 10:16:50 FYI my problem was this, should've googled instead of duckduckgo'd https://stackoverflow.com/questions/34290289/yocto-using-bbappend-file-to-override-writing-of-default-init-scripts-for-initr Jan 14 10:19:12 @rburton hmm it is not in DISTRO_FEATURES but it is in POKY_DEFAULT_DISTRO_FEATURES, should that have some effect Jan 14 10:19:50 if its not in DISTRO_FEATURES then it doesn't have any affect Jan 14 10:20:43 being in POKY_DEFAULT_DISTRO_FEATURES just means that the poky default distro features include it, but you're obviously not using default poky Jan 14 10:22:05 ok thanks. What could override DISTRO_FEATURES_append = " ptest"? Jan 14 10:22:19 I would imagine that appends in every case Jan 14 10:27:42 thats what -e is for Jan 14 10:28:12 it will show you how DISTRO_FEATURES is evaluated, and importantly will show you if your assignment is being overridden, or not being parsed at all Jan 14 10:35:48 rburton hmm okay, it just shows one line of DISTRO_FEATURES, I'm not sure how to track it based on that information Jan 14 10:36:10 don't grep, write to a file and open it in less/your favourite editor Jan 14 10:36:22 above the assignment is the history of the evaluation Jan 14 10:39:23 Sponge5: great Jan 14 11:13:27 rburton thanks, Toradex new BSP had for some reason DISTRO_FEATURES_remove = "ptest" Jan 14 11:13:43 yeah that's dumb Jan 14 11:13:58 because you can't just reverse that with _append, remove wins Jan 14 11:15:32 to their defense, it is commented with "TODO: review default distro features" :D Jan 14 11:16:47 ha! Jan 14 11:39:37 stuom1: worst case scenario, you could suggest them to use what's "explained" in Chris's paragraph here: https://theyoctojester.info/session_14/main.html Jan 14 11:46:13 there appears to be a second repro bug in vulkan-samples :( Jan 14 12:13:28 hello guys.. I need a little help here. Jan 14 12:14:02 I have a device-tree append recipe that will compile system-top.dtb and copy it /boot/devicetree Jan 14 12:14:31 In order to that this recipe requires the do_configure task of the virtual/kernel Jan 14 12:14:56 on the other hand, the fitimage is generated by the virtual/kernel recipe Jan 14 12:15:30 and in order to have the fitimage with the dtb included I need to have the sytem-top.dtb in /boot/devicetree Jan 14 12:15:42 so there is like a circular dependency Jan 14 12:16:38 How can I mange that so that the device-tree recipe fetches the kernel compiles the dtb and only after that the virtual/kernel recipe is run ? Jan 14 13:14:28 Hi all:)  Stupid question : I have created a custom kernel module recipe (inherited from module). I have also a test-app. It's better to create a new recipe to build&install the app or i can add a task on the module inherited recipe ? Jan 14 13:23:24 I've used devtool to create a patch, tested it out with bitbake, it worked, then commited and devtool update-recipe'd, now when I try to bitbake the whole thing I get a whole bunch of "Patching symbolic link..." and then "Patch ... does not apply", any ideas? Jan 14 13:27:27 NiniC0c0: sounds like test-app is unrelated to the custom kernel module, so yes, separate recipe Jan 14 14:25:31 hello guys Jan 14 14:25:54 I'am facing a strange behaviour.. I've compiled  a whole distro Jan 14 14:26:05 burned on sd card and boot Jan 14 14:26:35 the strange thing is that the kernel boots, the filesystem is mount but I don't get any login prompt Jan 14 14:26:54 so I tried to nfs boot Jan 14 14:27:15 I can SSH to the board, but I can0t login from the serial terminal Jan 14 14:27:34 Why is that possible? Jan 14 14:32:47 thekappe: maybe no getty running on the serial console? Jan 14 14:34:24 erbo,  don't really know what getty is Jan 14 14:35:00 but I was just googling about it Jan 14 14:35:28 I expected the service to be there out of the box Jan 14 14:36:10 thekappe: what hw are you building for? Jan 14 14:36:53 FYI fixed my problem: had to rm -rf workspace/sources/, apparently bitbake tried to apply the patch to an already patched file Jan 14 14:37:38 if you know what tty the serial console is on, and you're using systemd, you could just try "systemctl start getty@tty1.service" . Assuming tty1 is the serial console tty. Jan 14 14:38:29 Sponge5: when you were done creating the patch, did you use e.g. devtool finish to tell it you were done? Jan 14 14:38:39 erbo, /etc/inittab -> 1:12345:respawn:/sbin/getty 38400 tty Jan 14 14:38:44 erbo: yes Jan 14 14:38:53 my serial is PS0 @ 115200 Jan 14 14:39:01 erbo: but apparently had to delete it too Jan 14 14:39:26 Sponge5: weird Jan 14 14:40:32 erbo: wait I didn't use devtool finish, but devtool reset nss Jan 14 14:40:41 erbo: and that wasn't enough Jan 14 14:40:56 didn't know about devtool finish Jan 14 14:41:41 thekappe: so no systemd? Jan 14 14:44:25 nope Jan 14 14:44:48 thekappe: I guess you should be able to see in ps output if getty is running Jan 14 14:45:14 i can see the kernel output Jan 14 14:45:27 not that getty is running Jan 14 14:45:36 and if from ssh i run $ cat "hello" > /dev/ttyPS0 Jan 14 14:45:44 I get Hello from the serial Jan 14 14:46:10 Yes, but in order to get a login shell you need something like getty running on that serial Jan 14 14:46:24 # ps | grep getty Jan 14 14:46:25  2123 root 3400 S /sbin/getty 38400 tty1 Jan 14 14:46:39 that's probably the problem Jan 14 14:46:44 yup Jan 14 14:48:08 thekappe: check what the SERIAL_CONSOLES variable is set to, it likely doesn't have an entry for ttyPS0 Jan 14 14:50:11 erbo, changing the line in /etc/inittab fixed the issue Jan 14 14:50:16 thanks dude Jan 14 14:50:24 smurray, I'll check it now Jan 14 15:10:28 smurray, SERIAL_CONSOLES does the trick. thanks Jan 14 15:10:44 thekappe: cool Jan 14 16:02:42 paulbarker: if your ears are burning its because we're talking about and leather on the triage call ;) Jan 14 16:02:49 argh Jan 14 16:02:57 'talking about you and leather' Jan 14 16:03:55 my ears were fine but now I'm worried Jan 14 16:04:03 :) Jan 14 16:04:28 vmeson pointed out that 'barker' historically is a leather tanner Jan 14 16:06:33 rburton: I've heard that, as well as that it was the associated with the town crier "barking" out notices Jan 14 16:13:30 ah, I forgot the call, I wanted to participate Jan 14 16:13:53 abelloni: still on if you want to join the party Jan 14 16:13:57 I now realize I never setup notifications... Jan 14 16:50:49 abelloni: Ah, next week for sure then! :) Jan 14 16:51:09 sure, I managed to join at the end Jan 14 16:51:51 abelloni: I noticed but assumed you were just observing :) Jan 14 16:52:04 indeed :) Jan 14 16:59:33 So is there absolutely NO DIFFERENCE whether I use UBUNTU or OPENSUSE? Jan 14 16:59:46 for yocto purposes I mean Jan 14 17:00:08 because they are both supported Jan 14 17:00:38 but its internals are different Jan 14 17:02:04 right, just use the distro you prefer Jan 14 17:32:02 rburton cool, thanks Jan 14 17:42:02 https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/rootfs.py#n223 Jan 14 17:42:02 I have a question regarding delayed postinsts. In OpenBMC we might use e.g. squashfs for rootfs and it always accompanied by RW fs mounted with overlayfs. The question is: what will be a better approach to allow delays postinst? Make it as configurable option (check for another IMAGE_FEATURES that clearly states about overlayfs)? Jan 14 17:50:16 rnouse: Do you need to allow them? If so, you could remove the read-only-rootfs IMAGE_FEATURE Jan 14 17:52:25 JPEW: I now can't get that reproducer I sent you to work. I am seeing the result of the g++ depend on cwd though :/ Jan 14 17:52:47 If you want, you can just send me the two ELF files? Jan 14 17:53:37 I had to write our own debug location decoder back when we ran our own RTOS so we could debug our code, so I have a little familiarity with it :) Jan 14 17:57:21 JPEW: you sound way better placed than me to understand this then. I'll send a couple of binaries over :) Jan 14 18:06:00 Hello khem for this repo https://github.com/kraj/meta-openwrt/tree/dunfell/recipes-tweaks/iptables there are two bbappend files . Usually a yocto build will have a single version of package and therefore my yocto build errors out complaining there is no version of iptable1.6 available as I only have iptables1.8. . Could you help me understand how do I use your repo and still compile iptables Jan 14 18:12:17 How do I deal with more than one bbappend file in a 3rd party repo. ie more than one bbappend file with diferent versions for same package Jan 14 18:13:31 kiwi_29: maybe you can BBMASK it if you can not delete it Jan 14 18:15:06 thanks khem. .. trying now Jan 14 18:40:41 JPEW: the rootfs is read-only and removing this image feature might brake other stuff. E.g. read-only-rootfs-hook wouldn't be called. I tho, we just need a way to relax this branch by an option. Jan 14 18:41:07 khem putting this. BBMASK += "meta-openwrt/recipe-tweaks/iptables/iptables_1.6%.bbappend" in build/conf/local.conf does not seem to be working Jan 14 18:41:21 I am definitely not doing this right. :( Jan 14 18:42:51 may be try recipe-tweaks/iptables/iptables_1.6%.bbappend Jan 14 18:43:03 or just iptables_1.6%.bbappend Jan 14 18:47:38 thanks khem just putting iptables_1.6%.bbappend worked ! Jan 14 19:06:07 rnouse: I guess it seems a little strange to me to say the rootfs is read-only... but not really Jan 14 19:07:09 # mount Jan 14 19:07:10 devtmpfs on /dev type devtmpfs (rw,relatime,size=432668k,nr_inodes=108167,mode=755) Jan 14 19:07:11 ubi0:rwfs on /var type ubifs (rw,relatime,assert=read-only,ubi=0,vol=2) Jan 14 19:07:11 overlay on /etc type overlay (rw,relatime,lowerdir=/etc,upperdir=/var/persist/etc,workdir=/var/persist/etc-work) Jan 14 19:07:12 as an example Jan 14 19:07:34 dev/ubiblock0_1 on / type squashfs (ro,relatime) Jan 14 19:08:22 rnouse: Sure, we do something similar, but in our 6 years of doing that, we've never needed a post-install script to run :) Jan 14 19:08:33 we need:) Jan 14 19:09:20 this is required for migration purpose between root and non-root running processes and files that are already present in read-write back-storage Jan 14 19:10:13 the best way is to provide pkg_postinst_ontarget_${PN} routine in per-package recipe that will chown/chmod files upon firstboot after update Jan 14 19:10:40 thus, we need a relax option for the check above in lib/oe Jan 14 19:18:14 RP: I think what's happening is that GCC is changing the order of the items in .debug_loc. I don't know *why* Jan 14 19:19:00 RP: Where did ParseHelper.cpp come from ? Jan 14 19:19:12 I could not find it in the Vulkan-Samples repo Jan 14 19:28:09 RP: Ah in a submodule... Jan 14 20:04:48 JPEW any thoughts on relaxing option? Jan 14 20:17:07 Does bitbake have a formal syntax definition for its config files, and why not? Jan 14 20:25:22 rnouse: It still doesn't quite make sense to me... I don't think you want *all* post-install scripts to run, some of them will surely fail because not all of your rootfs is RW Jan 14 20:36:50 Those post-install scripts are run during rootfs population, but the mentioned delays postinstall (pkg_postinst_ontarget_${PN}) present only in a few recipes: https://pastebin.com/tS9eBJVu Jan 14 20:46:16 imaami: Like a grammar definition? Jan 14 20:48:36 rnouse: Sure.... I guess I'm still skeptical. It seems highly specific to your setup as to whether those can actually run or not Jan 14 20:49:58 I guess maybe you can have some knob that you set that bascially says "I acknowledge this will only work if I validate all the pkg_postinst_ontarget for all the packages I'm installing only write to places I've marked RW" Jan 14 20:50:31 JPEW: if it were just order the size of the section wouldn't change? Jan 14 20:51:08 RP... Hmm. maybe. It's using some new-fangled GNU locview format I've never seen before Jan 14 20:51:34 DWARF does a lot of compression tricks, so it would not suprise me if an order change changed the size, but it could be something else also Jan 14 20:51:53 Or perhaps, the content changed, which caused the order to change Jan 14 20:52:27 JPEW: right, I'm out my depth :/ Jan 14 20:56:50 RP: Ya. Unfortunately, I'm having trouble finding the locview extension documentation Jan 14 20:57:03 DWARF is really well documented... the GNU extensions no so much Jan 14 21:07:33 Hi, for somethign like the iptables recipe what do the .rules file type mean? Is this a yocto thing or a linux thing ? Jan 14 21:08:11 JPEW: > I acknowledge this will only Jan 14 21:08:12 yeah, that's an original idea -- set the relaxing flag to bypass this check Jan 14 21:08:51 I see that the do_isntall uses those rules but how do you configure them for your specific image ? Jan 14 21:43:12 JPEW: any idea why the debug_str section would have the cwd at compile time embedded in it? Jan 14 21:43:36 JPEW: I simplified the test case down to a nearly empty file and am seeing that, seems a bit odd Jan 14 21:45:22 RP: No I don't Jan 14 21:46:51 RP: I didn't see that in the file you gave me Jan 14 21:47:09 Unless it's the "1/4 stride is too large" Jan 14 21:47:21 JPEW: no, I tried to trim the example down to bare bones and I see this Jan 14 21:50:15 JPEW: I'm seeing this even with my host g++ :/ Jan 14 21:51:30 Even with the debug prefix mapping option passed to g++? Jan 14 21:57:13 JPEW: I've messaged you the weirdness. I must be missing something obvious but the binary output depends on cwd :/ Jan 14 22:04:17 ya Jan 14 22:07:03 JPEW: I suspect in a larger more complex program the same issue could get abstracted away into debug_loc weirdness? particularly if the prefix was already remapped away by the prefix mapping Jan 14 22:07:33 I also suspect ninja isn't particular about its cwds Jan 14 22:12:03 Hmm, DW_AT_comp_dir seems suspect Jan 14 22:16:30 JPEW: ah, yes. Also https://patches.linaro.org/patch/77791/ - wonder if that was merged Jan 14 22:16:46 RP: Yep! that would do it Jan 14 22:17:13 I think the confusing thing with your example is that it outputs the string even when there is no debug data referencing it Jan 14 22:17:43 JPEW: right, but doesn't that patch imply it would do that? Jan 14 22:17:55 If you add a trivial function to the source instead of an empty file, it show up in the debug info pretty clearly Jan 14 22:19:25 JPEW: confirmed that code is in gcc so it will always generate it. I'm not sure if it should be optimised out or not Jan 14 22:21:15 It respectes -fdebug-prefix-map if that helps Jan 14 22:21:32 JPEW, so, what about relaxing option? Jan 14 22:21:45 JPEW: definitely does, just means we'd need to teach vulkan about keeping cwd sane Jan 14 22:22:58 JPEW: -feliminate-unused-debug-types -feliminate-unused-debug-symbols didn't help Jan 14 22:26:01 RP: Hmm, I don't really see what vulkan is doing that is so different... but I haven't looked *too* close Jan 14 22:30:06 JPEW: right, it is setting a consistent directory by the looks of it so I think I've just veered into a quagmire trying to simplify the testcase Jan 14 22:30:43 JPEW: sorry, it did look like a promising lead Jan 14 23:44:24 Hello everyone, please I need some help. I started running a build using the poky-contrib repo and specifically paule/rpurdie-license-experiments-osls branch. I had some errors at first but after rebasing on top of master my build was up and running well until this other error showed up. Here's the error I got. Jan 14 23:44:48 https://www.irccloud.com/pastebin/IhT9N80U/error Jan 15 00:54:42 my image's modules.alias file seems to be mostly empty. how would i debug that? Jan 15 02:50:56 * paulg wonders why installed filesystem from a rootfs built in the last 24h has a random date from 3 years ago... Jan 15 02:51:26 Poky (Yocto Project Reference Distro) 3.2+snapshot-09c7fc6e5341bfadb0f6037e7294aee2454eedef qemux86-64 ttyS0 Jan 15 02:51:26 qemux86-64 login: root Jan 15 02:51:26 root@qemux86-64:~# ls -l /lib/systemd/systemd Jan 15 02:51:26 -rwxr-xr-x 1 root root 1722592 Mar 9 2018 /lib/systemd/systemd Jan 15 02:52:04 same for /bin/bash or whatever you choose to look at. Some kind of pseudo artifact? **** ENDING LOGGING AT Fri Jan 15 02:59:57 2021