**** BEGIN LOGGING AT Thu Oct 22 10:59:57 2020 Oct 22 11:17:58 What is The Best(TM) way to set up a CMake project in a proper way? Proper means: That I don't make the package maintainers job hard. My current thinking is as follow: My CMake project must not set the DESTINATION argument of install( ...). Oct 22 11:19:51 manuel1985: i think its perfectly fine to set DESTINATION Oct 22 11:19:58 manuel1985: just use standard functions and do not invent own ones? Oct 22 11:20:01 jsut don't hard code a path in there. Oct 22 11:20:15 my blueprint is https://github.com/TheYoctoJester/simple_echo_server/blob/master/CMakeLists.txt Oct 22 11:22:39 using GNUInstallDirs makes things a lot easier for packagers Oct 22 11:24:03 LetoThe2nd and hrw: Disagree. cmake.bbclass invokes cmake with `-DCMAKE_INSTALL_BINDIR:PATH=` hence there should be no reason to fiddle with this in CMakeLists.txt Oct 22 11:25:07 yup, AFAIK thats why i install to bin, not to "/usr/bin" or such. the example i provided installs to /usr/bin on a standard OE build. to me thats sane and expected. Oct 22 11:25:14 rburton: Agree, CMake honors these variables if GNUInstallDirs is used. https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#module:GNUInstallDirs Oct 22 11:26:17 I've seen things you people would not believe. configure scripts called from different dirs, cmake modules changing standard stuff just to make life harder, sick m4 macros... Oct 22 11:26:32 * hrw -> out Oct 22 11:26:43 i've never actively pulled in gnuinstalldirs, but i see the described behaviour. hm. Oct 22 11:28:30 LetoThe2nd: Perhaps there are some distros around which come up with something like "bin64", hence I thought about not setting DESTINATION *at all*. Just to be on the supersecure side. Oct 22 11:29:19 i tend to just use the simplest and most obvious setup until it breaks. Oct 22 11:29:33 My feeling is also that CMake honors these variables like ${CMAKE_INSTALL_BINDIR} in every case, not just when GNUInstallDirs is used. However, seems to claim different: https://cmake.org/cmake/help/latest/command/install.html#installing-targets Oct 22 11:31:54 Oh I think I just read the docu wrong. Oct 22 11:31:54 "For regular executables, static libraries and shared libraries, the DESTINATION argument is not required. For these target types, when DESTINATION is omitted, a default destination will be taken from the appropriate variable from GNUInstallDirs, or set to a built-in default value if that variable is not defined." Oct 22 11:33:22 So, if CMAKE_INSTALL_BINDIR is set, it is used. If not, go with the default. Oct 22 11:33:57 so i implicitly and without actally knowing have already used gnuinstalldirs, it seems. Oct 22 11:34:32 Ok but then the next pargraph is very misleading. It effectively claims the opposite. Oct 22 11:34:32 "The following table shows the target types with their associated variables and built-in defaults that apply when no destination is given:" Oct 22 11:37:28 LetoThe2nd: Your live coding session on package splitting got me thinking about all this :) Oct 22 11:39:53 I f****** hate CMake documentation Oct 22 11:40:03 What are your oppinions on Meson? Oct 22 11:47:23 i personally gave it a try some time back and didn't like that it includes some pre-defined target configurations like release, debug,... Oct 22 11:47:55 but that might be just me, i see it being used in many noteworthy projects. Oct 22 11:48:42 Hmm. I see. We're now partly switching to Meson as it seems to be what GStreamer is using. Oct 22 11:49:24 and systemd, and... Oct 22 11:49:53 I love systemd, though Oct 22 11:55:30 same here. Oct 22 11:57:48 Systemd and the AWS CLI are shining examples of a clean CLI interface. Docker is a nightmare. Oct 22 12:12:24 I'm trying to install some python dependencies into a Yocto image (in custom bb files), and one of them calls kernel functions, namely "shm_unlink" which once booted is undefined. I'm not much of a C developer, I'm assuming there's some linker issue or I'm missing something in the image. If someone could point me in the right direction I'd be grateful. Oct 22 12:15:57 "which once booted is undefined"... what does that mean? sounds like you are copying over something pre-compiled instead of actually building for the image. Oct 22 12:24:23 LetoThe2nd: python dependencies seem to be built by creating a bb file, adding "inherit pypi setuptools", and naming the file after tha package desired. I've done this, it works well. But one of the python packages, "posix_ipc" calls on some functions from (https://github.com/mruffalo/posix_ipc/blob/master/posix_ipc_module.c#L1048) but at runtime this is not found and I just plain don't know Oct 22 12:24:29 what I'm missing in the recipe. Oct 22 12:26:25 why should it search a header at runtime? Oct 22 12:26:33 something is completely wrong here. Oct 22 12:27:31 LetoThe2nd: upon importing posix_ipc in python, I get "ImportError: /usr/lib/python2.7/site-packages/posix_ipc.so: undefined symbol: shm_unlink" Oct 22 12:30:25 If the package is installed on the target, using pypi (pypi install posix_ipc) all is fine. Oct 22 12:30:33 pip, rather Oct 22 12:30:40 pip install posix_ipc Oct 22 12:37:12 Androo: thats because in the first case you are crosscompiling, and something is messed up. in the latter case, you are compiling in-target Oct 22 12:37:47 that posix_ipc.so is not python, its a compiled binary. plus, as you are on python 2.7, you are totally out of luck and support anyways. Oct 22 12:42:32 Fully understand the problem, just not the solution. It's a linking issue that I thought might be easily solvable. Oct 22 12:43:41 (just not by me, of course, and where does one go to get paid support for cross-compiling on Yocto ... I would pay!) Oct 22 12:43:49 the solution is probably to properly package posix-ipc Oct 22 12:45:31 this is an attempt at properly packaging it, unless i'm misunderstanding what a proper package for it would look like Oct 22 12:58:09 i am no python guy, hence i cannot hepl with the details, sorry. i can just guess that something in the compilation stage is broken. Oct 22 12:58:13 leon-anavi: maybe? ^^^^ Oct 22 13:02:47 I'm grateful for the attempt, thank you. I work for a company in the IoT space, and we're trying to learn Yocto to properly produce images for one of our products (traditionally we've just been using Debian and copying the image directly off one of our devices) and it's been a journey! Oct 22 13:06:18 welcome to the club! erm.. jungle! erm... welcome anyways! Oct 22 13:10:48 Androo: there are plenty of consultancies who specialise in yocto and can help migrate from other systems to Yocto Oct 22 13:11:05 rburton: any recommendations? Oct 22 13:12:19 https://www.yoctoproject.org/community/consultants/ is a starting point Oct 22 13:12:26 well, leon-anavi as one of the main meta-python contributors works for the konsulko group, for example. :) Oct 22 13:12:41 i can think of a few who are not on that list though Oct 22 13:15:37 it really depends (TM) but the list is a good starting point. Oct 22 13:18:33 rburton, LetoThe2nd: all of this is a good starting point, thanks much. So far my hurdles have been overcome by sheer will and patience, so I'll likely try more of that first because it's clearly holes in my knowledge that are at issue, but it's good to know there might be somewhere I can turn to if I give up on myself. Oct 22 13:20:08 Androo: for generic python packaging questions you can also try and poke moto-timo, who will probably around in a couple of hours here Oct 22 13:29:47 Androo: i'm *guessing* your shm problem is the the prober.py in that repo Oct 22 13:29:57 Androo: it tries to run some code, which isn't going to work in a cross environment Oct 22 13:31:56 How does Yocto calculate the taskhash for a python function? Does it include all "see" the d.getVar calls? Oct 22 13:34:17 rburton: I'm thinking "-lrt" is needed (see line 361 of prober.py) in this environment, and perhaps this file does not put it there? Not sure. Maybe I should fork this library and modify a few things. Oct 22 13:34:23 correct Oct 22 13:34:36 setup.py is terrible at building code in cross environments Oct 22 13:34:43 rburton: i've noticed! Oct 22 13:34:54 y u no nodejs? :P Oct 22 13:35:21 LetoThe2nd: there's a lot of bad decisions made about our app that I am tasked to eventually clean up Oct 22 13:35:54 Androo: rule #1 of this channel: do not take me seriously, unless i'm being seirous. Oct 22 13:36:11 rule #0: ignore LetoThe2nd Oct 22 13:37:09 rburton: sounds like a plan! Oct 22 13:37:43 ernstp: IIRC, the sstate-cache stores all variables used by a task and their value. So if a variable changes, it triggers a rebuild of the task. I'm not entirely sure but for me "taskhash" actually means the hash of the content of the task (like... "plain text" content). In that case, no, the taskhash does not include "all see d.getVar" but taskhash AND dependent variables are part of the task's Oct 22 13:37:45 sstate-cache Oct 22 13:39:46 qschulz: I mean for bash script the variable is just evaluated and then the task hash is simple. And sstate-cache simply uses the task hash as key, right? But for the python d.getVar() calls it must be more complicated... Oct 22 13:40:43 ernstp: haven't looked at the code but I think I remember people saying there was some smartness around detecting uses of d.getVar from within a task. Oct 22 13:40:48 qschulz: it must somehow determine _before_ running the function if it can use the cache or it should be run again... Oct 22 13:41:05 ernstp: anyway, you can what makes up a sstate-cache by running `bitbake-dumpsig -t recipe task` Oct 22 13:41:18 you can check* Oct 22 13:41:41 qschulz: ah, thanks. that should be helpful... Oct 22 13:45:33 LetoThe2nd, thanks for mentioning my contributions to meta-python. I'm catching with the conversation right now. Oct 22 13:45:46 leon-anavi: :) Oct 22 13:47:48 qschulz: right, it certainly detects d.getVar variables in task dependencies, so all good! Oct 22 13:51:05 LetoThe2nd, I think we have meta-python in pretty good shape. Most (not all) of the recipe are up to date with https://pypi.org/ Oct 22 14:49:09 Hi all, can we use bash parameter expansion inside recipe ? in my case ${DISTRO#*-} is still empty but ${DISTRO} contains the good value Oct 22 14:49:38 Hi, I'd like to add an FPGA bitstream to my image, but I use copy&paste and call a command line script, is there a better way, say is it possible to use yocto for this? Oct 22 14:50:28 guest2134: adding a binary file to the image is trivial. running some script also is, it it does not need to be executed at runtime. Oct 22 14:51:22 guest2134: see https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#packaging-externally-produced-binaries Oct 22 14:51:35 do you have a tutorial how to write an image recipe that runs a script after compilation? Oct 22 14:52:06 guest2134 You can also take a look if the vendor provide meta-xyz for your FPGA Oct 22 14:52:06 addtask my_script after do_compile? Oct 22 14:52:28 guest2134: it really depends on what the script is supposed to do. Oct 22 14:53:27 LetoThe2nd it calls Quartus Oct 22 14:53:43 (with the output from yocto) Oct 22 14:53:48 in the workdir Oct 22 14:54:00 now that does not make any sense at all. Oct 22 14:54:35 you said: "I'd like to add an FPGA bitstream to my image". now it sound like "i want to add my image to something" Oct 22 14:54:49 and the latter is a completely different thing. Oct 22 14:56:04 The Quartus programmer generates the FSBL from the U-Boot output, uses the bitstream and generates the image Oct 22 14:56:13 https://rocketboards.org/foswiki/Documentation/GSRD131GettingStartedYocto Oct 22 14:56:44 guest2134 to be honnest it's exactly what I do with Xilinx product Oct 22 14:57:04 * LetoThe2nd is out, no idea about these things. no fpga guy. Oct 22 14:58:34 Do you know what the IMAGE_PSOTPROCESS_COMMAND does? Oct 22 14:59:23 guest2134: https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-IMAGE_POSTPROCESS_COMMAND ? Oct 22 14:59:27 it is clearly stated in the manual... Oct 22 14:59:38 I'm having a hard time adding a kernel module to my image...think it's because the module is 32 bit...anyone have any pointers? Oct 22 15:00:27 Can I use IMAGE_POSTPROCESS_COMMAND to call a shell script? Oct 22 15:00:58 Or do I have to use add a task? Oct 22 15:01:53 guest2134: functions != tasks Oct 22 15:02:03 functions are shell only IIRC Oct 22 15:02:10 carlsb3rg: its certainly not because of 32bit per se - builds are completely 32b and no problems at all. so you're probably missing out some(many?) important details Oct 22 15:02:21 Ah okay, thank you qschulz Oct 22 15:05:38 I get a bunch of warnings that all of the shift lefts are larger than the data type and pointers are incompatible...then finally an error saying: asm/unistd_64_x32.h: No such file or directory Oct 22 15:06:35 so it at least has something to do with 32<->64, but maybe I'm missing an option Oct 22 15:14:47 when bitbake builds, it's looking at the kernel source in /usr/src/kernels instead of build/tmp/work-shared/geodelx/kernel-source/ - that might be the problem? Oct 22 15:15:17 carlsb3rg: almost certainly, but then your module makefile is broken. Oct 22 15:15:55 I'll look...might be a variable... Oct 22 15:16:42 but the module is from the board manufacturer so I would prefer not to touch it...might end up having to patch tho Oct 22 15:22:15 carlsb3rg: here's a neat example on how the Makefile of an out of tree module has to look like if it shall be properly crosscompile-aware: https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Oct 22 15:24:50 the proper way to do it (according to the manufacturer) is: KERNEL_DIR := /lib/modules/$(shell uname -r)/build Oct 22 15:25:13 thanx for info...I'll patch it... ;) Oct 22 15:25:48 Makefile from 2004... :D Oct 22 15:25:56 the manufacturer is clearly wrong here. Oct 22 15:26:34 need to add some symlinks inside sdk, what would be the right approach? Oct 22 15:26:54 The irony is the comment in the Makefile: Oct 22 15:26:59 # Kernel build environment directory. Supposedly it is safer to use this# method of referring to it than using /usr/src. Oct 22 15:27:11 it's all wrong...lol Oct 22 15:27:40 time to patch... Oct 22 15:32:01 carlsb3rg: probably KERNEL_DIR ?= would work just fine Oct 22 15:32:10 because supposedly Yocto is passing its own KERNEL_DIR Oct 22 15:32:32 carlsb3rg: check all other variables that they aren't hardcoded either Oct 22 15:37:18 yeah...I was thinking of patching it from KERNEL_DIR := to KERNEL_DIR ?= or maybe just KERNEL_DIR := $(KERNEL_SRC) which i think is what Yocto uses Oct 22 15:38:06 carlsb3rg: yeah seems like KERNEL_SRC is the correct value from https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/module.bbclass Oct 22 15:54:25 possible dumb question: bitbake core-image-minimal builds an image, bitbake virtual/kernel builds the kernel, bitbake virtual/bootloader the bootloader, etc. Is there a single command to build kernel, bootloader and rootfs? Oct 22 15:57:43 Hi all, I'm working on adding a new Python recipe using devtool. I used `devtool add` to clone the sources locally and devtool was able to infer that the recipe used setuptools, so it already contains `inherit setuptools3`. However, when I try to build it, I get a ModuleNotFoundError in the `do_configure` stage: "No module named 'setuptools'" Oct 22 15:58:02 I've done this process before with other Python packages without any difficulty. Does anyone know what might be causing this particular package to have this problem? Oct 22 16:00:41 The package in question is cvxopt: https://github.com/cvxopt/cvxopt Oct 22 16:02:43 guest2134: usually, you'd put virtual/kernel, bootloader, etc... in EXTRA_IMAGEDEPENDS in your ,achien configuration file Oct 22 16:06:29 Ah, that makes sense Oct 22 16:10:22 hmm...I put PREFERRED_PROVIDER-virtual/kernel and INIT_MANAGER in machine/[name].conf...can you do it with EXTRA_IMAGEDEPENDS instead? Oct 22 16:10:28 can/should? Oct 22 16:15:42 carlsb3rg: PREFERRED_PROVIDER_virtual/kernel only tells yocto IF and only IF there is a dependency somewhere on virtual/kernel which recipe to build Oct 22 16:15:53 carlsb3rg: it actually does notghin more than that Oct 22 16:16:11 carlsb3rg: INIT_MANAGER would be better in a distro conf file IMO Oct 22 16:16:29 it does not make much sense to me to force an init manager depending on which machine your building Oct 22 16:19:02 I actually put INIT_MANAGER in my distro.conf myself Oct 22 16:19:28 now that I checked... Oct 22 16:22:27 @LetoThe2nd: Python does all the checks at run time, not at build time. You could try to use some static code checker which could tell you dependency issues at build time. https://github.com/priv-kweihmann/meta-sca/blob/master/docs/sca/buildtime_dependencies.md Oct 22 16:29:26 RobertBerger: idk if that was meant for me or not, but in either case it answered my question. Thanks! Oct 22 16:30:49 @gpanders: It really helped me to work out dependency issues in Python to add meta-sca with some python checks. Oct 22 16:31:05 @gpanders: at build time Oct 22 16:31:34 @gpanders: as a nice side effect coding style issues were resolved as well. Oct 22 16:31:40 in my case, my problem was that I was using `DEPENDS =` instead of `DEPENDS +=`. So I was overwriting the setuptools3 class Oct 22 16:32:01 I see. Oct 22 16:32:06 RobertBerger: what flags did you use Oct 22 16:33:49 gpanders[m]: the class should be using _append really so that can't happen Oct 22 16:36:04 @dl9pf: you mean for the python stuff? Oct 22 16:36:44 rburton: _append or += ? I see both used in poky. Is one "better" than the other for any reason? Oct 22 16:36:48 yes Oct 22 16:36:54 _append happens afterwards Oct 22 16:37:07 so even if your recipe did DEPENDS=foo Oct 22 16:37:21 the _append would still happen and add setuptools-native Oct 22 16:38:22 @dl9pf: SCA_ENABLED_MODULES_IMAGE_PYTHON = " pyfindinjection pylint " Oct 22 16:38:22 well, there's a reason most recipes sdefine DEPENDS before inherit :) Oct 22 16:38:38 @dl9pf: SCA_ENABLED_MODULES_RECIPE_PYTHON = " bandit cspell pyfindinjection pylint pysymcheck radon rats " Oct 22 16:40:47 RobertBerger: cool, need to try that out Oct 22 16:41:25 @dl9pf: check this: https://github.com/priv-kweihmann/meta-sca/blob/master/docs/sca/buildtime_dependencies.md Oct 22 16:42:04 Hello all, Is there way in which I can override do_install[noexec] = "0" from a bbappend file (the bb file sets it 1 do_install[noexec] = "1" as a result my do_install isnt being invoked) Oct 22 16:45:17 prabhakarlad: I think you can set it back in the bbappend. I think bbappends are always processed after the .bb file (although the order between multiple bbappends can be trickier) Oct 22 16:46:05 prabhakarlad: set it to the empty string, not 0 Oct 22 16:46:12 prabhakarlad: if that doesnt' work, you can use anonymous python to delete the flag Oct 22 16:59:39 kergoth, JPEW: setting do_install[noexec] = "" in the bbappend file didnt help! could you please provide pointer on "anonymous python to delete the flag" Oct 22 16:59:59 prabhakarlad: python () { d.delVarFlag('do_install', 'noexec') } Oct 22 17:00:03 obviously not on one line like that Oct 22 17:05:39 kergoth: Thank you :) deleting did the trick! Oct 22 17:10:28 prabhakarlad: no problem Oct 22 17:10:38 prabhakarlad: i think there's actually an open yocto bug about that Oct 22 17:11:01 prabhakarlad: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13808 Oct 22 17:11:04 there it is Oct 22 17:12:41 kergoth: Thank you for the link and pointing out it was know issue. Oct 22 17:53:33 Hm, hitting an issue with dunfell builds on ubuntu 20 building qt5 where it runs incredibly slowly compared to other hosts nad also hangs up the system so much that you can't even ssh in. Oct 22 17:53:37 Anyone else hit this? Oct 22 18:05:25 kergoth: strange, any specifics from system load ? Oct 22 18:06:51 checking into that. i wasn' tthe one that hit it. and builds in ubuntu 20 under docker happen in a normal amount of time without any problems, so it's either specific to u20 with its kernel, or something about that particular host an dits resources Oct 22 18:09:57 yeah I have seen issues with ub20 but not perf related Oct 22 18:16:00 Is this the correct patchwork for oe-core? https://patchwork.openembedded.org/project/oe-core/patches/ The latest patches it shows are from 10/17 Oct 22 18:22:45 rewitt: yes it it,and there were issues with it last week but then halstead has fixed it, atleast it working again for oe-devel mailing list again not sure about oe-core ml Oct 22 18:25:12 khem: Alright, I'm sure if halstead is aware then it will be fixed Oct 22 18:27:22 rewitt, It should be getting patches again. I still need to resubmit patches that arrived while the account was bouncing. Oct 22 18:28:17 halstead: No worries, and thanks. I wanted to make sure it was still be updated before I assumed something was wrong. Oct 22 18:31:54 rewitt, There is a new smtp server I needed to whitelist starting yesterday. That's done. Oct 22 18:37:03 I'm getting permission errors when do_install tries to put my kernel module in /lib/modules...isn't pseudoroot supposed to take care of that? Oct 22 18:51:04 carlsb3rg: no. you have to install files to ${D} Oct 22 18:57:38 oki...thanks...I'll have to check into that tomorrow Oct 22 18:57:56 I see your point...just not sure how to edit my Makefile Oct 22 19:03:47 carlsb3rg: In case you haven't seen it https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Oct 22 19:06:47 I did...but think I've been a victim to makefile order of expansion stuff... Oct 22 19:06:53 i'll fix it tomorrow :) Oct 22 19:06:58 thanks guys Oct 22 19:39:49 RP: so I did an experiment with and without multilib for qemux86-64 ( without my patch ) and once I enable multilib its rebuilds everything target related, so my patch does not make it any worse Oct 22 19:40:13 RP: the second build it still in progress, I will check how much sstate got reused Oct 22 19:40:16 once its done Oct 22 19:59:12 Hi guys Oct 22 20:00:08 Have anybody wrestled with amd video card support? Oct 22 20:00:21 I am and I could not be more stuck Oct 22 20:15:00 lack of imagination? :) Oct 22 20:23:49 Sort of :D Oct 22 20:24:10 I am trying to drive a radeon device Oct 22 20:24:24 But meta-amd does not really help for me Oct 22 20:26:34 I have a mullins radeon r4/r5 Oct 22 20:27:18 Now I am trying to create the recipe on my own from the x.org sources Oct 22 20:27:54 linums: share details maybe someone has run into similar errors Oct 22 20:28:19 I don't know if it sounds reasonable after I failed with the meta-amd Oct 22 20:33:32 can i somehow have an alias for a machine? such that i can use either machine name foo or bar? Oct 22 20:35:06 derRichard: well you need separate files for best results Oct 22 20:37:38 @derRichard: do you want to use the same machine config for multiple machines? then you could just have dummy machines including the common machine config, but you will need to adjust the kernel recipe as well to be compatible Oct 22 20:37:50 i'd have the second include the first file and adjust MACHINEOVERRIDES so both overrides are applied Oct 22 20:38:54 @kergoth, but then they are not completely identical, since due to the override one is "stronger" Oct 22 20:39:57 currently i cleanup a yocto setup with strange machine names. i cannot rename them now because too many exteral tooling uses these names. so i'd like to do a soft transition and add aliases for the existing machines such that i can use the better names step by step. Oct 22 20:48:33 whats in a name ? that which we call a machine by any other name will cause as much pain - Khem'speare Oct 22 20:50:34 machine names such as "some-arm" are not really nice. especially since the layer now supports three different arm based socs :D Oct 22 20:51:05 So, what my problem is with the meta-amd, that it uses 3 machine parameters, and those seemingly does not produce x86-64 images Oct 22 20:52:33 So now I'm truing to build the driver based on the anongit.freedesktop.org/xorg/driver/xf86-video-amdgpu Oct 22 20:55:17 This results somehow multiple definition errors, and I don't really know why (i can see that the sources are present in 2 folders during the do_compile procedure, but after that, the second folder gets deleted, and I don't know how I could debug this issue) Oct 22 20:55:33 So this issue I can't resolve Oct 22 20:57:44 But also I doubt somehow, that amd support is even possible under yocto, and now I am wondering why radeon module recepie is only present in the meta-amd layers, and why is it soo barely updated Oct 22 20:59:16 I know that this is not a specific question, but after 2 weeks of suffering with the radeon kernel module I have no more definite question, sine I have no clear idea how to proceed :( Oct 23 03:21:37 ok people, who set up https://hub.docker.com/u/yoctoproject Oct 23 03:21:41 speak up Oct 23 05:26:13 Adafruit requests for SDWire and a USB 3.0 Mux equivalent sent... cross your fingers people Oct 23 05:26:42 Off the shelf automated testing commodity items for the win for all of us Oct 23 05:29:16 zedii: trying to KERNEL_FEATURES_append = " features/hugetlb.scc" for linux-yocto-dev ... shouldn't this work? Oct 23 05:29:24 zedii: ERROR: Feature 'features/hugetlb.scc' not found, this will cause configuration failures. Oct 23 05:29:52 * moto-timo goes to be entirely too late for the time zone I am pretending to be in Oct 23 05:46:31 might help if I used the actual path eatures/hugetlb/hugetlb.scc Oct 23 07:40:47 good morning Oct 23 07:56:06 yo dudX Oct 23 08:16:58 good morning, fine folks Oct 23 08:17:53 thanks for helps and tips with my kernel module challenges yesterday...had to patch both Makefile and c source, but finally got kernel module installed on this antiquated HW Oct 23 08:18:44 now gold plate it and sell it. gold antiquaries go at a premium price! Oct 23 08:29:19 lol...I'll see what I can do Oct 23 08:32:58 mckoan: glad you like the idea :) Oct 23 08:44:44 LetoThe2nd: yes, thank you Oct 23 08:45:12 mckoan: hi5 Oct 23 08:45:36 LetoThe2nd: we are preparing for lockdown-2.0 so I have to imagine new scenarios Oct 23 08:46:21 yeah, we're already in for some fun too. Oct 23 08:47:19 LetoThe2nd: I'm very sad because now I'd be packing my suitcase for Dublin :-( Oct 23 08:48:17 same here. yet actually i probably shouldn't complain as it does go along nicely with the current family situation, and as along as everybody is helthy, so be it. Oct 23 08:56:45 is it just me or could there be a poky-simple which is a stripped reference distribution specifically for learning purposes? Oct 23 08:58:29 the poky ref distro as is has loads of cool setups and recipes, but maybe at the cost of complexity Oct 23 09:00:32 as a complete n00b at both Linux and Yocto, the steep (understatement of the year) learning curve is tough...definately made worse by my first assignment being to create a distro on 17yo HW that has to boot in under 4s but still... Oct 23 09:01:18 my distro boots in 2.9s btw so I'm really happy...not bad for a n00b :D Oct 23 09:07:34 adelcast: i observed latest patch on the ML regarding permissions. i wonder: why check 'privilege' requirement at all? users might be using it just to install/manage packages into an offline root dir of their control Oct 23 09:09:38 carlsb3rg: you can build completely distro-less if you want to :) just comment DISTRO ?= "poky" out in the local.conf. Oct 23 09:17:43 sure...but even core-image-minimal etc is pretty heavy stuff...I'm still a bit overwhelmed by the link through core-image-minimal.bb -> core-image.bbclass -> image.bbclass and the plethora of tasks and other stuff in there Oct 23 09:21:55 carlsb3rg: i wouldn't worry too much about it. while it can be educating, this is more like stuff that is meant to "just work" Oct 23 09:22:59 and when it does, it's very nice :) but the void between starting up and "just work"-ing when you don't have an A4 case is pretty rough :D Oct 23 09:25:26 ? Oct 23 09:25:55 i can hardly see core-image-minimal not working when IMAGE_FSTYPES is correctly set. Oct 23 09:29:12 I'm doing IMAGE_INSTALL += "pciutils" in my custom image...should it be CORE_IMAGE_EXTRA_INSTALL += ... and I can do IMAGE_INSTALL += "kernel-modules", but should it be MACHINE_EXTRA_RDEPENDS += "kernel-modules"? Oct 23 09:31:02 there's loads of ways of doing stuff that seem to work, but are they best practice? why should I choose one over the other? So while I appreciate that things often "just work", the engineer and coder in me want to know why it works and what is the preferred way of getting things working Oct 23 09:31:41 it depends on where you to it. your custom image that pulls in core-image-minimal or such should happily be able to IMAGE_INSTALL += "". this is just very problematic due to expansion order in local.conf or appends, hence it should be avoided there. CORE_IMAGE_EXTRA_INSTALL is meant to inject stuff ad-hoc through local.conf Oct 23 09:33:15 for the "kernel-modules", it entirely depends on if the machine will not even boot properly (e.g. the kernel setup NEEDS the modules), then it shall go into the MACHINE_EXTRA_RDEPENDS. if it is something that the image needs, or even more specifically, some application in the image, then it should go into IMAGE_INSTALL, or even the specific kernel-module-xxx into the RDEPENDS of the application. Oct 23 09:35:38 and I guess that's the kind of info I'm missing...there's loads of ways to Rome and I feel like I'm killing best practice fairies every second line I add in a .conf or .recipe :D Oct 23 09:38:08 carlsb3rg: hehe yes, thats how it is with systems as complex as those. the problem is that there are so many tings to tune and understand that its almost impossile to document them in a way that suits everybody. so we went for the "document everything as good as possible" approach, which unfortunately means that the documentatino can be a bit overwhelming if you are just starting out Oct 23 09:38:27 but maybe you just have accept that you're not going to get everything right/correct at first and that becoming good is an organic process no matter how many tutorials and docs and stuff you find Oct 23 09:39:43 carlsb3rg: thats certainly true for most of us, yes. Oct 23 09:42:16 RP: if I run "bitbake packagegroup-core-x11-xserver -c clean" and then build my image, the setscene tasks are running as expected, so I see no reason why populate_sdk_ext failed to find them. Fun enough on next run the problem switched to packagegroup-core-boot.do_populate_lic Oct 23 09:43:09 I guess my situation has been made worse by the fact that I (without prior knowledge of Yocto or inner Linux) got a project where I had a couple of weeks to upgrade a Yocto 1.6 project to 3.1 on HW that was EOL a good while back :P Oct 23 09:44:20 and the guy who hacked together the 1.6 version with hammers, nails, pre- and post-image patches etc left the company years ago and no-one here has even heard of Yocto :D Oct 23 09:45:05 yann: from what I remember the error you're seeing means its not finding them within the eSDK it's built so it is quite a different codepath Oct 23 09:45:31 yann: obviously it should but I can see how the context is very different Oct 23 09:45:46 carlsb3rg: thats also true for many of us. but my opinion is that this is something to be blamed on company processes and decisions, not on the YP. problems with advanced, undocumented internal things causing troubles when the guru leaves are certainly universal Oct 23 09:46:43 RP: it does not happen in the eSDK itself, but within standard bitbake env while dunning do_populate_sdk_ext Oct 23 09:47:14 but using the sstate from our CI Oct 23 09:48:25 the problem would appear to be with something that "do_clean" removes then Oct 23 09:49:05 yann: eSDK ends up running bitbake within bitbake to test the eSDK and I think your failures are there Oct 23 09:49:08 not blaming YP at all...merely trying to suggest (and maybe even assist) in ways of making things easier for other n00bs...clearly a bad decision by the company had made it a tough experience...at least I'm adamant in not doing any hacking...if you checkout the right version of poky and my layers, it's a one-liner to get the distro built... Oct 23 09:50:04 carlsb3rg: well, we have all that. see the live coding session on kas. Oct 23 09:52:26 RP: how can I check this is the case ? and how would do_clean change what's hapenning ? Oct 23 09:53:28 yann: did you have any tasks you'd run using bitbake -f ? Oct 23 09:54:46 LetoThe2nd: Think I binged the live series a bit too hard...I'll checkout #12 again Oct 23 09:55:41 carlsb3rg: kas essentially gives you exactly that. a one-liner that checks out all layers in a known state, sets the configuration and builds a defined target. Oct 23 09:55:55 not that I remember - at one point though bitbake complained that it thought my kernel had been forced (which I'm pretty sure is not true, though I did request specific tasks locally for config tweeking) and a good do_clean on that recipe got rid of the issue. But even if not accurate, that message was explicit Oct 23 09:56:29 yann: if you had, it would show warnings in each build Oct 23 09:57:19 I confirm there is no such warning right now Oct 23 09:57:24 yann: debugging this problem is one of the reasons Paul and I were never happy with eSDK, its hard. I can try and talk you through it but I really need logs to look at and so on, its not straightforward :/ Oct 23 10:03:33 eh, it's not that obvious from the talks that there are such annoying issues with eSDK :) Oct 23 10:09:30 yann: I'm quite sad we've never improved it, its purely a time thing Oct 23 10:10:29 I have a couple of patches pending verification that should improve some things, but not that one :) Oct 23 10:16:35 * clementp[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/qhNtKVGNzOrDzTGberhuCOVt/message.txt > Oct 23 10:19:47 Oups sorry for the Matrix URL -_- Oct 23 10:20:02 I would like to test my local kernel before pushing my patch to git. Oct 23 10:20:05 Is there an easier way than adding a .bbappend with the KERNEL_SRC using protocol=file Oct 23 10:20:05 and SRCREV=${AUTOREV} Oct 23 10:20:09 e.g : in Buildroot I set the env variable _OVERRIDE_SRCDIR=~/my-repo Oct 23 10:20:09 Is there something similar or what do you use as dev for your local test before pushing ? Oct 23 10:20:09 Thanks for your answers Oct 23 10:20:52 clementp[m]: the kernel manual should have a section exactly how to do that using devtool Oct 23 10:21:37 Hello all, I'm still working on distros managment and it's a really cool adventure. Last question remaining: I have to distros and i want to add some packages according the distro. The better way is to use DISTRO_FEATURES or there is an other way to do that ? Cheers :) Oct 23 10:22:32 In fact I have mydistro-dev and mydistro-prod and the goal is to add only debug tools to the 1st one :) Oct 23 10:24:59 Ninic0c0: I would definitely go with DISTRO_FEATURES but distros are also available in OVERRIDES so you could do: IMAGE_INSTALL_append_mydistro-dev for example Oct 23 10:25:58 qschulz: ++ Oct 23 10:29:47 qschulz LetoThe2nd Thx guys I will do it :) Oct 23 10:31:09 and now I'm wondering if you can't have an IMAGE_INSTALL_append in your distro configruation file too mmmmmmm Oct 23 10:31:24 (still should go with DISTRO_FEATURES, but wondering :) ) Oct 23 10:32:18 qschulz: IMAGE_INSTALL_append += will probably work, but its kind of besides the point Oct 23 10:41:05 Ninic0c0: to be honest, using distros for prod vs debug might be overkill Oct 23 10:41:57 rburton: oh c'mon Oct 23 10:42:50 here you go: https://youtu.be/MlzTET_8SQg Oct 23 10:48:10 Hi I just wondering if there is possibility to make for example a whole bbappend conditional like u-boot_%.bbappend_your-platform-override ? Oct 23 10:48:54 dev1990: no but you can make all variables/tasks in your bbappend your-platform-override specific Oct 23 10:49:12 yeah I did that but I endup with bunch of overrides Oct 23 10:51:51 Is there a posibility that future bitbake will support something like that? Oct 23 10:52:41 dev1990: meta-arm does this http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm-bsp/recipes-bsp/uefi/edk2-firmware_git.bbappend Oct 23 10:53:03 dev1990: at one point if you have too many different things, you might want to create a new recipe that is specific to this hardware and use PREFERRED_PROVIDER_u-boot for it Oct 23 10:53:31 rburton: nice trick Oct 23 10:54:28 when you have so many machines to deal with it's kind of essential Oct 23 10:54:28 http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.3.bbappend Oct 23 10:54:48 seven machines there, another two queued, and ~4 in the pipeline Oct 23 10:56:08 ok this might be useful, thanks :-) **** ENDING LOGGING AT Fri Oct 23 10:59:57 2020