**** BEGIN LOGGING AT Tue Feb 02 02:59:57 2021 Feb 02 05:48:41 hi! i'm running into a funny issue on my vmware based buildservers: when updating to dunfell the python-setuptools-native package crashes with SIGILL. Feb 02 05:50:23 this seems to be caused by a bug in glibc-2.32: https://sourceware.org/bugzilla/show_bug.cgi?id=26534 ... and while dunfell seems to use 2.31 it seems that it is pulled in by uninative Feb 02 05:50:56 what's the best workaround for this? Feb 02 06:43:43 qschulz: I can see it here: https://lists.openembedded.org/g/openembedded-core/message/147452 Feb 02 08:06:02 yo dudX Feb 02 08:24:12 LetoThe2nd: hi Feb 02 09:35:20 LetoThe2nd: morning! dare we ask how much sleep you got? :) Feb 02 09:36:16 RP: somewhere in the average range, i'd say. so chances are that my behaviour is not completely as erratic as it was yesterday ;-) Feb 02 09:37:10 LetoThe2nd: ok, just curious :) Feb 02 09:37:40 RP: totally valid question, no doubt. Feb 02 09:47:01 good morning Feb 02 09:51:33 the headache continues, so I thought I could go about my problem with asking a very very simple question: on a cmake based project that I am trying to make into a recipe (it produces executables and a library - and that's the problem) , what does the cmake has to do to get the library installed. basically once the recipe builds, the build directory Feb 02 09:51:34 contains a bin/ with my executables and that gets installed ... and a lib/ directory which never makes it to the image/ directory much less to package/ or packages-split/ or deploy-rpms/ so what does the library CMakeLists.txt has to do to get the library installed? Feb 02 09:53:10 the library is versionned and linked to a .so and I have tried everything under the sun that I and others could think of to no avail so open to suggestions ... Feb 02 09:53:59 intera91: not sure it helps, but i've succesfully done basically the same with this minimal approach: https://github.com/LetoThe2nd/libanswer Feb 02 09:54:17 the executable which depends on that library finds it in lib/ subdirectory of build and therefore compiles fine Feb 02 09:57:29 LetoThe2nd: thanks having a look now Feb 02 13:49:51 LetoThe2nd quick note to the Jester , I searched up the definition of Jester and I got three: 1. One given to jesting. Feb 02 13:49:52 2. A fool or buffoon at medieval courts. 3. A story-teller; a reciter of tales, adventures, and romances. Feb 02 13:50:02 So which one is correct? Feb 02 13:52:16 usr8392123: (2 + 3) Feb 02 13:52:42 :') (y) Feb 02 13:57:25 is there a layer for bpi-m2 zero? It is an h2 allwinner, perhaps I can use the orangepi layers? Feb 02 13:58:52 kayterina: http://layers.openembedded.org/layerindex/branch/master/machines/?q=banana&search=1 Feb 02 13:59:24 there isn't one for lichee pi nano unfortunately... Feb 02 13:59:48 but I'm pretty sure you should be able to use mainline linux and u-boot, you just need to create the machine conf file yourself Feb 02 14:00:11 @qsch Feb 02 14:00:20 qschulz yes indeed Feb 02 14:26:35 can you explain how I will use mainline linux for bpi? Will I use bsp from meta-sunxi? Am I reading the correct page here: https://linux-sunxi.org/Mainline_Kernel_Howto ? Feb 02 14:30:28 kayterina: using linux-yocto should probably suffice, you'll just need to pass it the correct defconfig (sunxi_defconfig?) and device tree in variables that are set in your machine configuration file Feb 02 14:51:31 simple question: how can I automatically run a script after the booting is done and I've logged into my machine? Feb 02 14:51:33 add it to boot sequence? Feb 02 14:53:52 if mr usr returns: https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj #15 :) Feb 02 15:22:03 We have udev starting before modutils is run, apparently because of 2011 "module autoload needs it to create device nodes" (says 69aac1a91f86). Any idea if this is still true ? It does not allow to use /etc/modules to force early load when modules init order matters. And as a matter of fact, on debian/testing (ok that's systemd) the kmod script is run way before udev Feb 02 16:00:15 i'll need to drop off the weekly call after about 30 minutes Feb 02 16:01:21 tlwoerner: I can pick up the minute taking if you ping me when you need to go Feb 02 16:01:35 paulbarker: okay, thanks Feb 02 16:12:14 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14207 Feb 02 16:27:13 paulbarker: i'll step away now Feb 02 16:27:21 tlwoerner: No problem Feb 02 16:35:11 vmeson: dude that hurt :) Feb 02 16:40:31 https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/895/steps/12/logs/stdio Feb 02 16:42:12 rburton: lol, of course you have nothing to be hurt about. :) Feb 02 16:47:28 https://mirrors.kernel.org/yocto/ Feb 02 16:49:37 sure are a lot of 2012 dates in that listing. Feb 02 16:49:45 wonder how many are still relevant. Feb 02 16:52:04 John Kaldas: https://wiki.yoctoproject.org/wiki/Newcomers Feb 02 16:52:19 --> Newcomer Bugs Feb 02 16:53:29 @vmeson: thanks! will check it out Feb 02 16:54:09 Guest1497: super, and find an IRC client and get a cryptic /nick ! ;-) Feb 02 16:55:12 vmeson: yeah right, would be better Feb 02 17:12:42 paulbarker: thanks again, really appreciate it Feb 02 18:36:07 paulg: we haven't made releases of some, others are just plain "dead" :/ Feb 02 18:36:49 paulg: suspect its mostly tiny apart from the yocto dir Feb 02 18:38:12 I was actually looking for mirrors of kernel.org itself, and happened across that by chance -- that korg was mirroring yocto. Feb 02 18:39:21 RP: the build failure on kernel is due to this Feb 02 18:39:22 [kraj@apollo /mnt/b/yoe/master/build/tmp/work/qemux86_64-yoe-linux/linux-yocto/5.10.5+gitAUTOINC+47c7a3148a_f08df324cc-r0/linux-qemux86_64-standard-build] Feb 02 18:39:22 % ./tools/objtool/objtool check --retpoline --uaccess arch/x86/kernel/smp.o Feb 02 18:39:22 [1] 1645539 segmentation fault (core dumped) ./tools/objtool/objtool check --retpoline --uaccess arch/x86/kernel/smp.o Feb 02 18:40:06 objtool seems to be coming from kernel itself but we are compiling it as host tool I guess and its not liking the objects produced with binutils 2.36 assembler Feb 02 18:41:13 since its checking for retpoline its x86 specific thats why we see it on x86 builds only Feb 02 18:56:15 Bitbake under Gatesgarth is giving me a nice warm fuzzy feeling when it reports download rates of 2736GB/s :D Feb 02 20:00:30 khem: ah, that wonderful code :/ This at least makes a bit more sense of things Feb 03 01:41:02 RP: I think I have kernel issue under control sent a v2 of binutils patchset **** ENDING LOGGING AT Wed Feb 03 02:59:57 2021