**** BEGIN LOGGING AT Fri Jun 26 03:01:39 2020 Jun 26 03:36:28 icu Jun 26 06:53:09 * alessioigor waves allDoes someone knows why when I change *only* DISTRO_VERSION the kernel without initramfs bundled is never rebuilt whereas the kernel with initramfs is always rebuilt? Jun 26 06:54:06 alessioigor, check with bitbake-diffsigs ? Jun 26 07:52:17 kanavin_home: i feel bombed... Jun 26 08:07:20 Hi. I was trying to auto-load a module using KERNEL_MODULE_AUTOLOAD in a systemd system. But it doesn't work, seems that systemd-modules-load.service doesn't exist. Is this a bug or I'm doing something very wrong? Jun 26 09:36:40 Qt is configured with xkbcommon only for x11, but qt apps through warning about missing xkbcommon when run on wayland, and this warning goes away by adding xkbcommon in qt packageconfig Jun 26 09:37:56 is this understanding right thta Qt with xkbcommon is not X11 specific? Jun 26 09:38:57 xkbcommon.org says it run in various platform including Wayland Jun 26 10:47:36 I want to make native recipe. what is the better way to do it: 1) with BBCLASSEXTEND += native or 2) myrecipe-native_XX.bb ? Jun 26 11:04:18 dv|2: Does it make sense to build your recipe for the target as well? Or just native? Jun 26 11:05:01 or to rephrase: it "DEPENDS" :) Jun 26 11:06:50 paulbarker, mainly to ba able to add DEPENDS += "myrecipe-native" (help tool to bild other recipes). It should be included into SDK and target also, I think. So both - native and target. I'm planning to add "lerna" tool (If you know NodeJS) Jun 26 11:07:22 lerna to target? *lesigh* Jun 26 11:07:47 dv|2: It's pretty obvious then. If you go with (2) you'll only be able to build for native. If you go with (1) you can build for native + target. Jun 26 11:14:30 paulbarker, thank you! Jun 26 11:15:20 Letothe2nd, yes! I have a big emmc so customer may want to install node module that requires build-tools and lerna... Jun 26 11:16:05 btw, anybody there able to see the problem with dunfell npm.class ? Jun 26 11:17:05 npm.bbclass I mean Jun 26 11:32:23 Hello all, after upgrading our yocto from zeus to dunfell I got this issue: "Exception: FileNotFoundError: [Errno 2] No such file or directory: '/mnt/DATA_2/Ns/YOCTO/build/tmp/deploy/licenses/cust-base-image/recipeinfo'" any idea to fix that ? Jun 26 11:33:02 from /cust-base-image.bb:do_populate_lic_deploy task Jun 26 11:47:09 ndec: https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/2075/steps/8/logs/step2d - from your fix :( Jun 26 11:48:17 RP: hmm. maybe it's a bug in explode_dep_versions2() ;) Jun 26 11:48:25 let me check! Jun 26 12:00:30 RP: ok, i can reproduce.. i tested with meta-stm and meta-poky.. looks like meta-yocto-bsp fails.. Jun 26 12:01:51 LAYERDEPENDS is empty, that's why it fails.. will send a v2.. Jun 26 12:06:06 ndec: thanks Jun 26 12:29:33 RP: I think the new arrangement where I pre-test my patchbombs on the AB works rather well - I will not be bombing in july most likely, as I will be in a lake cabin Jun 26 12:31:26 RP: v2 sent.. Jun 26 13:08:10 kanavin_home: If we know you're not doing it we may try and keep things up to date Jun 26 13:08:26 kanavin_home: it does seem to work, yes. Its nice to look roughly up to date Jun 26 13:23:06 Someone here could give me some info about recipeinfo file ? Jun 26 13:44:47 RP: I mostly want to avoid big bang/total recipe rewrite version upgrades (e.g. python 3.5->3.8), I think I've done my share of those :) Jun 26 13:45:26 apt was the last, now we're good Jun 26 14:46:08 halstead: around ? Jun 26 15:43:57 Good morning zeddii. Jun 26 15:44:06 sent you an email with the details. Jun 26 15:45:20 Thanks. Jun 26 17:41:17 Has anyone built an sdk targeting x32? I'm running into an issue where the cross-canadian toolchain in the sdk fails to find any libraries, it seems like it didn't obey BASE_LIB/baselib to search libx32, but gcc-cross works fine Jun 26 17:41:29 I'm not super familiar with our gcc build, though Jun 26 17:45:04 kergoth: I don't think that is in the test matrix fwiw Jun 26 17:45:18 ah, good to know Jun 26 17:47:47 the x32 gcc binaries in the sdk are symlinked to the non-x32 binaries, but it wasn't built with a multi-lib configuration, so it always uses 'lib', not 'libx32', regardless of whether i'm building for x86_64 or x86_64 -mx32 Jun 26 17:47:50 afaict Jun 26 17:47:56 hmm Jun 26 17:48:21 is anyone using x32 anymore? Jun 26 18:23:35 I am a little stuck.. I have an external-arm-toolchain ive been working on (that packages up a toolchain installed on the host). It works as expected however... I want to compile some things with clang. So I have the meta-clang layer. When I set TOOLCHAIN="clang" those packages get the error "tmp/hosttools/ld: unrecognised emulation mode: Jun 26 18:23:35 armelf_linux_eabi" Jun 26 18:24:04 Any ideas what I might have done wrong that makes clang use the hosttools/ld? Jun 26 18:25:10 Oh and yes if I skip the external-arm-toolchain and use the yocto generated one.. things work. Jun 26 18:25:34 So i'm sure its my fault :) Just not sure what to look for Jun 26 18:54:36 rabbit9911: Are you using the ARM toolchain from meta-arm? Or writing your own recipes/classes? It's not clear from your question Jun 26 18:54:45 Also what Yocto Project version are you using? Jun 26 19:16:03 I have a toolchain generated from crosstool-ng thats pre installed. I am writing a yocto recipe to package up that toolchain for building yocto recipes. Jun 26 19:16:31 I am using dunfell Jun 26 19:22:40 My current thought is that there is a missing ld link missing in my PATH.. so the next ld in my PATH is tmp/hosttool/ld? Jun 26 19:23:09 still looking at that.. no idea if that is even possible.. seems strange. Jun 26 19:42:20 rabbit9911: Writing your own toolchain integration is probably one of the more advanced things you could do with Yocto Project. I don't expect it to be straightforward Jun 26 19:43:05 I recommend looking at the external-arm-toolchain support in meta-arm and seeing what you can learn from that Jun 26 19:44:29 meta-external-toolchain has logic that searches in multiple locations and handles differing toolchain layouts, so it's probably doable, but it's definitely non-trivial to integrate still Jun 26 19:44:42 i've spent the past 4 days working on adding support for oe's own sdks as an external toolchain.. Jun 26 19:44:46 and i'm still not done Jun 26 19:45:25 the layer index should list a few external toolchain layers that work as examples, they take different approaches depending on which copied from where when Jun 26 19:47:11 meta-sourcery is a good example of a layer that builds upon meta-external-toolchain for more specific requirements, you don't have to copy everything to make an external toolchain layer, so that's a slightly different approach than most Jun 26 19:47:30 I did start with external-arm-toolchain. It seems to mostly work.. Jun 26 19:48:06 I had to modify some things... but pretty much the same recipe. Jun 26 19:48:09 maybe ask khem if he knows if anyone has worked with clang and an external toolchain? afaik he's done a lot of the work on clang and musl Jun 26 19:48:16 * kergoth shrugs Jun 26 19:50:16 i used to prefer the single recipe approach, since you can just grab the whole sysroot, but then you run into headaches with not knowing what your PROVIDES needs to be based on what the sysroot contains, can conflict with other recipes, etc. but the more granular external toolchain recipes have their own pain points Jun 26 20:04:16 So clang is just configured to use the wrong linker somehow. Going to look at the clang CMakeLists.txt and cmake.bbclass next. Jun 26 20:36:26 how to migrate from yocto rocko to thud Jun 26 20:37:32 is there any guide for the same Jun 26 20:42:23 can anyone help in yocto Jun 26 20:43:06 jdfree: there is a section in the manual about migration Jun 26 20:43:23 (for each release) Jun 26 20:45:19 Why thud and not zeus? Jun 26 20:48:18 i am a newbie, the manual provide only the changes takes place in the version, do we have a guide on how to Jun 26 20:48:38 as i have a lot of local layesrs Jun 26 20:49:52 rabbitt9911: it is a specific need, want step by step increment in upgrade Jun 26 20:50:19 jdfree: wouldn't you start with rocko to sumo then? Jun 26 20:51:25 jdfree: the manual details the changes made to the core between each release series. We can't know what that means for any given layer and I doubt such a guide is possible Jun 26 20:55:47 RP yes i can go from rocko to sumo Jun 26 20:57:41 my doubt is if i copy all the existing layers from rocko to the new version do i have to make any changes to the config files Jun 26 20:58:42 and if i have to what all precautions i need to take Jun 26 20:58:54 jdfree: we have no idea what is in your config files so its impossible to say Jun 26 20:59:44 jdfree: presumably this is a new clean build environment you're doing this in and you can regularly rebuild whatever it is from scratch so you should be limited in the issues you can cause by trying? Jun 26 21:13:10 Personally I like to keep the poky directory 100% clean of any changes. My layers are external to poky directory. So jumping between poky versions is pretty easy just a matter of fixing your recipes Jun 26 21:13:36 rabbit9911: that is how its meant to work :) Jun 26 21:14:42 (y) Jun 26 21:15:06 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/2068 - your patches I'm afraid Jun 26 21:15:21 JPEW: do we have to have a flag day with the client/server changing together Jun 26 21:15:22 ? Jun 26 21:16:32 (this is an old server with new client changes) Jun 26 21:26:51 RP: The new server can support old clients, but not the other way around Jun 26 21:30:11 argh, can't use a multilib oe external toolchain with a non-multilib external tcmode build as things stand today, due to the particular libdir paths in use. the fact that it puts x32 binaries under lib64/x86_64-oe-linux/10.1.0/x32 instead of the expected libx32/x86_64-oemllibx32-linux-gnux32/10.1.0 is a problem.. unless i grab the other arch paths *too* when pulling the external files.. Jun 26 21:30:12 hmmm Jun 26 21:30:23 * kergoth scratches head Jun 26 21:30:27 i must be missing something Jun 26 21:31:17 kergoth: could some symlinking help? Jun 26 21:31:40 JPEW: thanks, I can safely upgrade our hashequiv server to this and we should be ok then? Jun 26 21:32:40 i think i might need to check for a symlink in the current found gcc libdir (64, 32, x32) and follow it to its destination, then also include those files.. not sure, though Jun 26 21:33:23 RP: Yes... I can't remember if I explicitly checked for that so let me try it quick before I have you break everything ;) Jun 26 21:33:35 s/checked/tested/ Jun 26 21:34:25 JPEW: thanks, I'm a bit nervous of breaking this Jun 26 21:35:04 RP: understandable Jun 26 21:35:08 JPEW: autobuilder hashserv db is 16GB Jun 26 21:35:13 Heh Jun 26 21:35:37 Well, good news is that I'm fairly confident it wont corrupt the database Jun 26 21:40:23 JPEW: that is something, I think I had better make a backup though... Jun 26 21:41:07 RP: Probably wise Jun 26 21:42:00 the system in question isn't enjoying the large files Jun 26 21:42:41 RP: OK, I just verified and the new server supports the old clients Jun 26 21:42:59 JPEW: thanks. I will update things and see what happens Jun 26 21:45:26 there we go, got my heuristic auto-selection of which environment-setup script to parse for tcmode-external-oe-sdk to work. now to sort out this missing crtbegin.o with my x32 multilib build issue.. Jun 26 21:46:11 checks TARGET_ARCH, TARGET_OS, baselib, and then if TUNE_PKGARCH is included int he environment-setup, will check for it in PACKAGE_ARCHS in the env-setup Jun 26 21:50:35 kergoth: I keep dreaming there must be a better way to work with these toolchain paths Jun 26 21:55:13 JPEW: for fun I watched the cpu usage of the hashequiv server whilst we triggered a build on the autobuilder. Peaks at 36% cpu so far which isn't so bad Jun 26 21:55:29 halstead: you might find the above interesting Jun 26 22:28:38 * halstead nods. Jun 26 22:58:30 any reason EAT_TARGET_SYS not matching TARGET_SYS would cause trouble? Still trying to figure out why clang-cross-arm is using hosttools/ld linker. Jun 26 23:16:14 Seems like because the TARGET_SYS linker is not found.. the host linker is used... but I really want the EAT_TARGET_SYS linker.. Jun 26 23:17:28 any ideas? The EAT_TARGET_SYS=arm-ca9v3-linux-gnueabihf TARGET_SYS=arm-poky-linux-gnueabi Jun 26 23:18:10 This is only a problem when trying to use TOOLCHAIN=clang with the meta-clang layer Jun 26 23:22:41 I've run into issues with that mismatch previously with gcc, search paths might not be matching up, depending on how clang does library path searching Jun 27 00:07:40 Seems like I have to patch clang to use the EAT_TARGET_SYS name when searching for a linker? Or I have make my TARGET_SYS name match.. but its a weird triple that breaks some packages on config. Jun 27 00:07:55 yay compilers **** ENDING LOGGING AT Sat Jun 27 02:59:57 2020