**** BEGIN LOGGING AT Fri May 07 02:59:57 2021 May 07 03:45:15 ok thanks much khem! May 07 07:26:54 Hello all, I'm still stuck with a WSL2 issue, devshell doesn't put me inside the right folder and put me inside the HOME folder. Adding -D to the call point a trouble with terminal ... Any idea to run devshell inside WSL2? May 07 07:57:35 good morning May 07 08:05:28 HI May 07 08:06:12 how is any package disabled other than not defining in PACKAGECONFIG May 07 08:19:49 hi anyone May 07 08:51:08 Nithesh: see PACKAGE_EXCLUDE May 07 09:33:58 Hi! I have a tricky Ethernet pre-up configuration issue (yocto 3.1 + u-boot 2018.03 + linux-fslc-5.4.41 + imx7d + micrel ksz8081 phy), where should I ask for support? May 07 09:37:03 stedo: NXP since it's their kernel I think? May 07 10:38:19 morning I have a recip that has both a cross compile and a native part, when issuing bitbake -c cleanall -b recipe-native it does not clean anything and bitbake recipe-native compolains that nothing is found in the build/tmp/x/86-64/recipe directory May 07 10:39:12 on't use -b May 07 10:39:15 how do I restart build from scratch of that component as bitbake -c cleanall -b recipe does not delete the content of the native build directory May 07 10:43:27 JaMa: "bitbake -c cleanall recipe"  does not work either as it re-creates an empty build/tmp/work/x86-64/recipe-native directory and fails compilation because it is emnpty May 07 10:45:13 JaMa: got it it's working now May 07 10:45:29 had to issue a bitbake -c cleanall recipe-native May 07 10:45:32 thanks May 07 10:47:48 intera_91: bitbake recipe -C unpack May 07 10:48:03 cleanall is overkill May 07 10:48:31 or if you've broken the tmp directory though manual operations, just delete it May 07 11:00:11 Hmm, still struggling with sstate umask, in the cache it creates: May 07 11:00:12 drwxr-xr-x 2 pokyuser pokyuser 334 May  7 09:58 /workdir/build-nano/../files/bitbake/sstate-cache/48/41 May 07 11:00:12 I had expected this to be 775 so we could share the sstate-cache between users May 07 11:16:31 Hi All i have bb recipe which is proprietary and not included as part of local.conf but even then poky complains "ERROR: ExpansionError during parsing xyz.bb Permission denied, please try again." May 07 11:19:13 is there a way I could tell yocto not to do so ? May 07 11:31:56 PNBLACKLIST[xyz] = "1" might skip the parse earlier enough May 07 11:32:19 but typically it will want to at least parse everything May 07 11:33:10 Saur: rburton: can one of you maintainers please merge https://lists.yoctoproject.org/g/yocto/message/53345 ? May 07 11:33:27 yes, sorry May 07 11:33:47 thanks May 07 11:43:53 rburton: thanks that did the trick! May 07 11:47:31 JaMa: done May 07 11:48:46 rburton: thanks May 07 11:57:40 I have a "metadata is not deterministic" on my image's do_rootfs, but 1. -Sprintdiff does not show any diff, 2. -Snone regerenates the "same" sigdata over and over again, ie it overwrites the previous run with same name and a content for which bitbake-diffsigs says "no diff", though they don't even have the same size. Diffing the sorted output of bitbake-dumpsigs does not show any obvious issue, other than the usual data shuffling in sets. Any idea what could May 07 11:57:41 be the problem ? May 07 12:10:47 compiling a source from a Makefile using pkg-config in the Makefile results in an error in qa:The compile log indicates that host include and/or library paths were used. May 07 12:11:33 compile log: warning: library search path "/usr/local/lib/" is unsafe for cross-compilation (result of the `pkg-config` in the makefle May 07 12:12:10 is it possible to use pkg-config in a Makefile? May 07 12:14:41 ok stupid me found the problem May 07 12:20:11 RP: I wrote a test for orphaned ptests, and it revealed 14 items! May 07 12:25:23 kanavin: I thought there might be a few May 07 12:25:38 kanavin: will be interesting to see where we stand with them May 07 12:26:22 RP: I did some debugging on my sstate problem and within the build the files are created with the expected file mode but after the run the files have mode 755 for dirs and 644 for files. I suspect that your guess that this is related to pseudo is correct. Unfortunately I have no idea how to fix this. (the user running bitbake already does so with May 07 12:26:23 umask 0000 but that does not help) May 07 12:27:27 eFfeM1: I can only really suggesting filing a bug and hoping someone finds the time to debug it :/ May 07 12:28:09 eFfeM1: I did see some issues sharing between two users locally too. You could possibly hack around it with a cron job changing the modes May 07 12:29:24 RP: no problem, actually I'm not sure about what the access rights of a file created under pseudo should be. I kind-a expected that they would be the same and that only the UID is different, but apparently my expectation was wrong May 07 12:46:37 ticket submitted .... May 07 14:46:33 hello, is anyone familiar with the error: QA Issue: No GNU_HASH in the ELF binary May 07 14:48:28 google only speaks of that error in termns of libraries owing to be linked. in this case its is the program that is displaying that error not the libraries to which it is linked May 07 14:48:57 the yocto LDFLAGS is not being used by the linker May 07 14:49:25 the message should be changed, but basically we set the hash type in LDFLAGS so if the hash type is wrong in the binary, we know the ldflags were not used. May 07 14:49:48 @rbu May 07 14:50:06 rburton: how do I correct that? Makefile? recipe? May 07 14:50:17 depends on the recipe and makefile May 07 14:50:21 but yes, those May 07 14:50:43 patrick_r: https://docs.yoctoproject.org/ref-manual/qa-checks.html?highlight=ldflags May 07 14:51:02 in the recipe, LDFLAGS has linker flags. they need to be passed to the linker somehow. obviously, that is dependent on how the linker is called. May 07 14:51:04 (just to point to the docs, follow whatever rburton is saying right now :) ) May 07 14:51:25 Why, after 45mins of test run did it throw a single warning right at the end May 07 14:52:41 because it hates you May 07 14:55:18 rburton: adding TARGET_CC_ARCH += "${LDFLAGS}" to the recipe just worked ... thanks ;-) May 07 15:00:38 (imho, that's cheating) ;) May 07 15:17:04 rburton: saw an internal recipe doing the same thing as that, and said exactly what you just did :D May 07 15:26:27 if I have a -native helper, and it runs find on the host right out of the build, and fine right out of the installed location (when I exit the do_install() early), but it coredumps when run after packaging finishes. And the binaries are a few bytes different after the packaging runs. One would assume that either strip is being run (doesn't look like it), or something else .. What would someone grep on to May 07 15:26:27 figure out what is actually changing that binary ? May 07 15:26:37 s/find/fine/ May 07 15:27:09 zeddii: I'd guess uninative May 07 15:27:41 zeddii: we call patchelf on them May 07 15:27:57 this is a go-native build application, so I'll grep around and see what I can figure out. May 07 15:28:29 zeddii: meta/classes/uninative.bbclass: subprocess.check_output(("patchelf-uninative", "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT) May 07 15:29:15 can that be inhibited ? (I'll grep and find out myself). May 07 15:29:29 zeddii: inhibiting it is bad so not easily May 07 15:29:38 https://pastebin.com/Nq5S5wiE May 07 15:29:50 see the one that works, the installed one that doesn't and the minor size different. May 07 15:30:06 I aborted the do_install() early and ran that same installed binary, and it is fine at that point. May 07 15:30:36 zeddii: you could try calling patchelf on it manually, confirm that breaks it May 07 15:30:57 * RP doesn't enjoy patchelf bugs May 07 15:31:03 will do that. looks not too bad a command line to cobble it together May 07 15:31:25 zeddii: might even be in the WORKDIR/temp log files May 07 15:31:48 RP: I'd bet is isn't common to have go apps as -native either. so that could complicate things. May 07 15:31:51 zeddii: is this master? May 07 15:32:22 yah. master + my WIP meta-virt stuff to multi-layer OCI containers. May 07 15:33:01 zeddii: if patchelf breaks it, might be worth hacking together an latest patchelf-native upstream revision and seeing if that works any better May 07 15:33:11 but one step at a time I guess May 07 15:33:34 ack'd. I'll run down that angle. and see if I can confirm it is that which breaks it .. but it does seem like the likely thing. May 07 15:43:36 is there a shortvcut I can use in do_install to place a file in /usr/share/applications/ in the recipe's do_install ??? May 07 15:53:24 patrick_r: nothing beyond mkdir/install May 07 15:54:02 is there a recommended way to handle upstream tgz shipped with other ones bundled in a zip file, like https://community.cypress.com/t5/Resource-Library/Cypress-Linux-WiFi-Driver-Release-FMAC-2020-04-02/ta-p/250424 ? May 07 15:55:42 @rburton install ${S}/app.desktop ${D}/usr/share/applications/app.desktop should therefore work right? May 07 16:07:53 RP: as predicted. May 07 16:07:54 https://pastebin.com/YLURmLa9 May 07 16:12:25 none of the newer commits on the patchelf repo look like they'll help. May 07 16:15:16 zeddii: "fun" :/ May 07 16:15:55 some pretty terrible commit messages in the patchelf repo :D May 07 16:18:26 go (at least the compiler) may have been broken by patchelf for quite some time May 07 16:18:27 https://forum.snapcraft.io/t/patchelf-broke-my-binary/4928 May 07 16:19:28 zeddii: I'd not be surprised. patchelf does some interesting things May 07 16:19:48 yup. and the issue is still open: https://github.com/NixOS/patchelf/issues/146 May 07 16:19:58 and centred around go. May 07 16:44:29 RP: I'll run them one by one locally May 07 16:44:43 (newly re-discovered ptests) May 07 16:46:28 RP: We should mentally note that go and patchelf are in fact broken. but I was able to dodge it after reading the uninative bbclass. May 07 16:47:08 luckily this package's go build actually works in -static mode (they don't universally), so I switched to -static for the native variant. and of course patchelf no longer runs on it and breaks it. May 07 16:50:17 kanavin: you could just add them to the fast list and see what a build of ptest-fast on the AB shows in the results May 07 16:50:55 zeddii: noted. If you have a cope of the breaking binary it may be worth stashing it in a bug? May 07 16:50:59 a copy May 07 16:51:19 RP: I would want to quickly fix things up where possible or move to appropriate lists (_slow or _problems), I have a local image ready, and already verified new expat with it May 07 16:51:53 I can create one with the various bits and pieces. I put links to the upstream issues in my recipe, so I can put them in there as well. May 07 16:53:28 kanavin: makes sense, I was just suggesting it as a way to check the results and see timings May 07 16:54:05 zeddii: it will need someone to sit down and stare at the breaking binary and the patchelf code... May 07 18:21:31 RP: I am running python3-numpy ptest now, and that made me wonder: should we enable multiple cpu cores in qemu? I can imagine things like numpy tests will benefit from that directly. May 07 18:21:49 RP: it's easily done via -smp option to qemu, each core is mapped to a thread on the host May 07 18:21:56 RP: we already use it in mbition. May 07 18:22:15 and of course multicore guest becomes closer to real world systems May 07 18:23:23 RP: it could be done for the ptest image only too May 07 18:29:07 RP: I could try throwing just that one change to the AB (across all images and targets) and see what falls out May 07 19:00:17 kanavin: I have been meaning to do that actually, I like the idea May 07 19:00:38 kanavin: Maybe just limit to 2 or 4 cores May 07 19:23:03 @zeddii/RP: I tried the latest and greatest master branch of various layers today and noticed that icecc was unhappy because of patchelf not found. Like "WARNING: shared-mime-info-2.1-r0 do_compile: Cannot use icecc: patchelf not found" May 07 19:23:42 I guess you fixed something on the uninative and now it's happier? May 07 19:31:51 RP: smp patch http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/qemu-smp&id=838d9368887549a01345a9da34e8ed22968f3e2a May 07 19:32:01 RP: will start on the AB as soon as maintenance is done I guess May 07 20:20:33 khem at al.: if all the kernel configs need to be supplied for a new architecture within a yocto linux kernel, then why use a yocto linux kernel at all? i.e., why not just use the "mainline" kernel? May 07 20:26:36 kanavin: can we keep it to 4 please just so parallelism doesn't hurt us May 07 20:31:50 RP: sure, I was just feeling adventurous :) May 07 20:48:33 yates: I'm not sure I follow the question. You are expecting some sort of magic configuration generation ? May 07 20:49:15 the configuration and the kernel content are related, but othogonal, so I don't see what you are wondering about. May 07 20:53:56 zeddii: kernel "content"? i don't follow you May 07 20:54:57 the actual kernel code. May 07 20:58:26 alright, forget my previous question(s) and let me ask a new question: May 07 21:00:38 if an architecture is already supported in the mainline kernel (i.e., in the arch folder) for a specific kernel version, then what is the advantage of using the yocto linux derivative of that kernel? May 07 21:01:45 one thing i see is that yocto-linux provides a BSP for the arch/board (e.g., qemuriscv32). is that the only advantage? May 07 21:01:51 it's not a derivate. It's bit for bit the same on many branches. It is there for a predictable cadence of updates, versions and testing against the core userspace. May 07 21:02:46 then why do you call it "yocto linux" and not simply "the linux kernel"? May 07 21:02:58 it's not called "yocto linux" May 07 21:03:20 it's linux-yocto, and you'd never, ever call it "linux" if it wasn't linus' git tree itself. May 07 21:07:03 you can call it sweet potato pie linux. the question is, what does it provide above and beyond the "linux" you get from a git clone of linus's kernel tree (with the appropriate tag)? May 07 21:07:39 you have a very strange way of asking questions. May 07 21:08:15 zeddii: you seem to be stuck in "zedii world"... May 07 21:08:22 cheers May 07 21:08:25 see ya' May 07 21:08:32 the yocto kernel development manual makes it extremely clear what value the workflow and repo organization provides, regardless of code particulars May 07 21:09:50 and also that folks can use whatever kernel they want. it is in core for the reasons I listed. Many use it, just as many don't. it isn't forced on anyone. May 07 21:10:45 kergoth: where is the "yocto kernel development manual"? i don't see it here: https://docs.yoctoproject.org/kernel-dev/index.html May 07 21:10:58 rather, May 07 21:11:16 here: https://docs.yoctoproject.org/ May 07 21:11:43 that kernel-dev index is exactly what i said, Yocto Project Linux Kernel Development Manual. literally exactly what i said with two extra words May 07 21:11:58 if you're going to be difficult just to be difficult, you're not going to get much help here May 07 21:12:27 @yates: try this: https://docs.yoctoproject.org/kernel-dev/index.html May 07 21:14:44 @yates: why don't you just compare what's the difference between linux-yocto and torvalds upstream? May 07 21:15:46 linux yocto and yocto linux are the same words i used, just with the order reversed, and i was sharply corrected. i am not trying to be difficult, but if you want to make words and order important for others, make them important for yourselves. i am not trying to be difficult. i thought i had seen another yocto manual on kernel development other than https://docs.yoctoproject.org/kernel-dev/ and was asking for it. May 07 21:15:53 @yates: just to throw in one more thing: I use yocto linux tooling and the yocto linux recipe together with an upstream kernel May 07 21:16:26 if you're pissed at zeddii, so be it, i didn't argue word order, so stop transferring your annoyance on the channel if you expect positive interactions May 07 21:17:33 RobertBerger: thank you for that datapoint. May 07 21:18:54 @yates if we would know what you are trying to do maybe this would help ;) May 07 21:25:12 RP: better version of qemu smp support http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/qemu-smp&id=2bd2965eee01c852d4304076acb62d7b97c29750 May 07 21:53:32 Hi folks. Just FYI I have just run benchmark for a Ryzen 5950x system with 128GB memory and created a pull request for https://github.com/shr-project/test-oe-build-time May 07 21:56:04 It only takes 2:37:29 on my workstation - compared to the reference 3:17:45 in the results list https://docs.google.com/spreadsheets/d/e/2PACX-1vSQmFvqik7MRumLafiZgwjE3IMLLcQY-71F3zNz9GuG8uzRb5FIp97uUqq6Qh3qWXQEWRK7Y9Hv2nXt/pubhtml# May 07 22:25:18 kanavin: oooo May 07 22:25:30 rburton, huh May 07 22:25:31 ? May 07 22:25:40 kanavin: re the smp patch May 07 22:25:54 rburton, mbition has had it since forever May 07 22:26:16 or rather mbient, the daimler's in house yocto distro May 07 22:26:33 kanavin: tsk for not getting it upstreamed ;) May 07 22:27:41 rburton, I need to check what else could be upstreamed, nothing springs to mind immediately May 07 22:27:54 rburton, I am starting at linutronix on 1 August May 07 22:29:04 kanavin: looks good, not sure that will work on mips/ppc so handy to have a way to override it May 07 22:29:43 RP: yeah, x86-64 works well, but I have no idea how other targets will react. Will override as needed. May 07 22:29:55 please work nicely for arm please work nicely for arm May 07 22:30:15 RP: particularly systemd-driven startups become even snappier May 07 22:31:51 rburton, virgl work, meta-gpl2 obsoletion, per image license checks, debuginfod, pretty much all recent features coming from me are derived from working at mbition and seeing product needs first hand May 07 22:32:15 kanavin: was the debuginfod work useful then May 07 22:32:22 kanavin: the smp thing is something I've been meaning to do for a while :) May 07 22:33:35 kanavin: I'm not happy about enabling pam by default. May 07 22:33:57 rburton, not yet, it needs to make its way downstream. We currently use a debugfs which is cumbersome and very slow to create given that our basic rootfs is 10Gb of daimler bloatware.. May 07 22:34:13 RP: why? May 07 22:34:43 kanavin: because we are meant to be an embedded configurable system and pam is rather heavy. This is effectively forcing it everywhere May 07 22:35:03 RP: but only in poky, not in oe-core May 07 22:35:42 kanavin: I suspect if we change that, it will create a lot more work as people will not test the non-pam codepath and it will break lots May 07 22:36:36 RP: I wonder if libpam can be built without pam in DISTRO_FEATURES, that prompted me to do it May 07 22:36:46 libpam-ptest should be exercised May 07 22:37:25 and until now it wasn't which isn't better than not testing non-pam May 07 22:37:51 kanavin: from what I remember, pam is pretty invasive to a few packages so I suspect it really is a true distro_feature May 07 22:38:20 it is, but do you really need pam enabled in shadow, etc to be able to run the libpam ptests? May 07 22:38:22 * kergoth yawns May 07 22:38:51 kergoth, probably not, but libpam recipe itself won't build without pam in DISTRO_FEATURES, so I could drop that instead May 07 22:39:31 kanavin: we could tag the libpam-ptest into some of the systemd testing May 07 22:41:11 RP: I would prefer not to complicate ptest handling if possible, and keep it down to three lists defined in a single file May 07 22:41:50 I also wonder how heavy pam *actually* is for an embedded system. We've had it left out for ages for that reason, but I don't recall what real actual impact there is. I bet the disk space usage isn't as bad as we thought.. May 07 22:42:02 yeah that too May 07 22:42:10 kanavin: I have lots of things I'd prefer too ;-) May 07 22:42:24 where's the 'heavy' claim coming from? May 07 22:43:11 i doubt anyone has looked closely at it since setting that default years and years ago, unless they had a specific requirement for it.. May 07 22:44:01 kanavin: what is your view on sysvinit? :) May 07 22:44:04 given it's installed on every linux system and macos, it's definitely unlikely to introduce risk, the only question would be disk space and possibly performance, but i doubt it greatly impacts login time either. probably was originally a disk space concern, back when we built tiny little images May 07 22:44:28 RP: 70s unix relic May 07 22:44:38 kanavin: right, and it isn't going anywhere either May 07 22:45:44 same as unix signals, /etc/passwd, x11, perl, all obsolete grandpa tech May 07 22:46:20 kanavin: but the project does need to continue to provide some of these things as not everywhere is all modern May 07 22:47:08 RP: yeah, I don't disagree, but here there was never any disagreement, it's systemd and wayland all the way May 07 22:47:35 kanavin: one of the project's values is being configurable and not forcing everyone into a one-size-fits-all. Somehow we need to continue to maintain the configuration ability May 07 22:47:59 kanavin: my instinct says that if we move pam from altcfg to the main distro config (and away from systemd), we're asking for trouble May 07 22:48:09 yates: I found the section in the manual we were mentioning before: https://docs.yoctoproject.org/kernel-dev/concepts-appx.html May 07 22:48:24 RP: right, but the 'heavy' claim does need to be substantiated a bit more May 07 22:48:51 RP: I'm fine if it stays non-default, I'm just not yet sure how to handle libpam-ptest then May 07 22:49:06 kanavin: we'll need to work something out for that, I think it should be possible May 07 22:49:12 * zeddii notes it could use some cleanup. versions, etc. May 07 22:49:45 RP: that is the latest doc link, I found right ? https://docs.yoctoproject.org/kernel-dev/concepts-appx.html May 07 22:50:04 I'll have to learn how to send patches to get it updated. May 07 22:50:13 * zeddii adds it to the ever expanding list. May 07 22:51:24 * RP wishes he could just say "no" to something and not have to justify everything all the time May 07 22:51:54 Providing reasoning is good and all that but it is starting to get to me May 07 22:52:19 can't the package listing just respect the distro feature? May 07 22:52:29 * rburton is only partially playing attention so just ignore me May 07 22:52:59 rburton: we only have one ptest run and it uses DISTRO=poky May 07 22:58:10 kanavin: I've replied to the patch so the discussion is on the list and others can comment May 07 22:59:58 rburton, libpam-ptest will probably go to PTESTS_PROBLEMS in that list, and pulled in elsewhere via altcfg-only setup May 07 23:00:50 RP: thanks, it's getting late so I'll sleep over it, don't want to open an editor now to find an alternative :) May 07 23:01:02 but I would want to toss that smp patch on the AB May 07 23:01:31 is the AB up and running again? May 07 23:02:39 kanavin: yes, its back, you can schedule it May 07 23:05:59 RP: I have become desensitized to small system needs, it won't be long before I'm out of automotive though :) May 07 23:07:38 oh god i'm bored of building chromium already May 07 23:11:29 kanavin: -rt is the other extreme, you'll want pam out soon enough :) May 07 23:11:42 rburton, RP https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2129 May 07 23:13:13 kanavin: cool May 07 23:15:41 RP: I have no idea what tglx has planned for me, I kind of just trust that it's going to be alright and I get the chance to do something new :) May 07 23:16:06 kanavin: right, I've no idea if -rt is involved :) May 07 23:16:29 kanavin: its just a bit of a contrast :) May 08 02:22:25 kanavin: why does tglx have plans for you? I must have missed something May 08 02:23:46 kanavin: give tglx my regards **** ENDING LOGGING AT Sat May 08 02:59:57 2021