**** BEGIN LOGGING AT Mon Mar 29 02:59:56 2021 **** BEGIN LOGGING AT Mon Mar 29 06:28:42 2021 Mar 29 07:39:06 good morning Mar 29 09:01:56 mornin' Mar 29 10:49:04 Hi, anyone an idea what is wrong with the following: Mar 29 10:49:04 I'm trying to write a recipe for a python package whose source is on github, but I end with a package: Mar 29 10:49:04 ./deploy-debs/aarch64/python3-bosdyn-mission_2.3.3-r0_arm64.deb Mar 29 10:49:05 there is no platform specific code in the package. (just py/pyc files) Mar 29 10:49:06 How do I set the right architecture? Mar 29 10:54:23 eFfeM1: what is the right architecture? Mar 29 10:55:57 qschulz I want to build for arm64 but the .deb ends up in aarch64 Mar 29 10:56:32 but effectively the package is architecture independent Mar 29 10:57:31 eFfeM1: aarch64 is the official name of arm64 Mar 29 10:57:54 facepalm; of course :-) Mar 29 10:59:10 qschulz I came here because my rootfs complained about mismatches, trying again now to get the actual error message back Mar 29 10:59:36 In the end, I think most python recipes aren't architecture independent from Yocto PoV. I guess because anyway they depend on the Python binary which is architecture dependent so the benefit is extremely minimal. Wild guess though Mar 29 10:59:51 runtime depend* Mar 29 10:59:57 makes sense Mar 29 11:00:06 eFfeM1: then let's have a look at this error first :) Mar 29 11:05:08 qschulz here is the end oof the do_rootfs log: https://pastebin.com/anrcVqqv Mar 29 11:05:17 lots of similar dpgt warnings before that Mar 29 11:05:27 dpkg: warning: package architecture (arm64) does not match system (amd64) Mar 29 11:07:40 aren't they architecture dependent because of the .pyc ? Mar 29 11:09:35 abelloni yes, actually the architecture dependency is not the problem, it is the issue in install Mar 29 11:09:37 abelloni: that would indeed make sense yes. But I'm not sure it is the issue? My guess right now is that the dpkg warnings are ok because dpkg is running on the building machine (amd64) to build the rootfs on the building machine for the target (which is arm64) Mar 29 11:10:23 eFfeM1: can you share the do_rootfs.log ? Mar 29 11:12:02 abelloni that is a bit hard as it is on a docker whose host I have to access via ssh, but you and qschulz helped me looking at the right place in the log and I now know what the issue is (but not yet how to fix it) Mar 29 11:13:47 The issue is that the src git repo actually contains sources for three packages, and do_rootfs fails with Mar 29 11:13:58  trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/__init__.py', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r0 Mar 29 11:14:42 whiich si the real cause of my problem Mar 29 11:15:03 eFfeM1: do you have multiple recipes for the same src git repo? Mar 29 11:15:23 basically the packages are in subdirs of the git repo, so I ended up with Mar 29 11:15:23 S="${WORKDIR}/git/python/bosdyn-mission" Mar 29 11:15:24 etc Mar 29 11:15:30 qschulz Yes! Mar 29 11:15:33 bitbake should have complained earlier Mar 29 11:16:17 3 recipes that buiild a python package in 3 different subdirs  of the same git repo Mar 29 11:18:12 oh and I am a bit of a python n00b; I was just asked to create a recipe for these three packages Mar 29 11:18:47 they are 3 different pip packages that in the end I want to get into my image Mar 29 11:20:05 I also tried a do_install() with body pip3 install bosdyn-mission etc but then of course it all ended up in sysroot-native or so, so that did not fly Mar 29 11:22:13 qschulz would it help if I carve one recipe that does three python3 setup.py calls  in do_compile and do_install ? Mar 29 11:24:42 why not just have three recipes that use the same SRC_URI Mar 29 11:24:54 as they're separate packages Mar 29 11:25:23 you *can* do what you want Mar 29 11:25:23 rburton that is what I have now and that gives me Mar 29 11:25:23  trying to overwrite '/usr/lib/python3.7/site-packages/bosdyn/__init__.py', which is also in package python3-bosdyn-choreography-client:arm64 2.3.3-r0 Mar 29 11:25:24 when adding all three packages to my image Mar 29 11:25:45 so presumably pip installing the 'top level' one is installing the others for you Mar 29 11:26:03 sounds like you don't really need multiple Mar 29 11:27:05 how i'd approach the 'multiple packages in a repo' thing is a custom do_compile that sets DISTUTILS_SETUP_PATH to $S/packageone then calls distutils3_do_compile, then DISTUTILS_SETUP_PATH=$S/packagetwo; distutils3_do_compile, etc Mar 29 11:27:18 that will run setup in each directory. ditto for install. Mar 29 11:27:41 but if there's a "top level" module that depends on the others, just install that and it looks like the dependencies are being handled for you Mar 29 11:29:34 yeah I was considering your multiple packages approach, I'll also peek at the dependencies. Will be after lunch though as it is now noon here, back in 30mins Mar 29 11:36:11 hey. I have a question. In the bb recipe I created I include a .inc file from another recipe in another layer. Everything would work but the .inc file pulls a patch in SRC_URI and of course unless I have a local "files" with that patch, it won't be found. Mar 29 11:36:19 Is there a way to do it "right" ? Mar 29 11:38:05 Hello, Im experiencing weird problem with my yocto and cant handle that alone, maybe someone here has experienced that. Mar 29 11:38:06 I got my new build machine and it works fast etc,  BUT, for few packages the build stalls. I mean - they keep rolling forever (now its over 5000s and cpu usage is almost 0% on all cores). I made some investination and I found out that for 4 out of 6 of there packages the build blocks on: Mar 29 11:38:06 ``` Mar 29 11:38:07 if [ -p /build/tmp/work/armv7ahf-neon-oe-linux-gnueabi/qtquickcontrols/5.9.7+gitAUTOINC+1afae24d7f-r0/temp/fifo.3554347 ] ; then Mar 29 11:38:07 ``` Mar 29 11:38:08 Do you have any ideas what could cause that ? I didnt touch this recipe and this build works wello n 4 other machines Mar 29 12:08:13 zbodek you could consider adding a FILESEXTRAPATHS_prepend or so to your recipe Mar 29 12:16:04 khem, can you look at https://gitlab.com/procps-ng/procps/-/merge_requests/126 please? Mar 29 12:18:31 eFfeM1: I could but then it would need to be an absolute path wouldn't it? Mar 29 12:18:57 eFfeM1: and the "files" directory is in another layer Mar 29 12:20:02 I suspect the layering is not a problem, the fact that it is a different package could be. Mar 29 12:20:59 If what you want to do is to create a  recipe for a different version best keep the directory structure the same (so the same folder in your layer) Mar 29 12:21:32 if you have a different recipe thaen consider if youu want to include an inc file from a different package Mar 29 12:22:08 and if you want a quuick and dirty solution copy over whatever you need; this is basically what I did when I had to go for an older version of python Mar 29 12:26:09 eFfeM1: copying of the files directory to have same structure works fine but I am afraid it won't be acceptable Mar 29 12:27:08 I'm trying to add a sample application to my layer, that will use this layer+recipe http://git.yoctoproject.org/cgit/cgit.cgi/meta-zephyr/tree/recipes-kernel/zephyr-kernel Mar 29 12:27:38 my recipe will look similar to this one http://git.yoctoproject.org/cgit/cgit.cgi/meta-zephyr/tree/recipes-kernel/zephyr-kernel/zephyr-philosophers.bb Mar 29 12:28:50 with an exception that the source code will be pulled from somewhere else. still I'm including zephyr-sample.inc which will pull the patch from meta-zephyr files via SRC_URI Mar 29 12:29:33 quite weird usage of meta-zephyr layer but I don't know how to attack it differently Mar 29 12:30:07 Im sorry I got disconnected, if someone replied to my question please repeat Mar 29 12:38:12 zbodek: I think you could probably setup a PREMIRRORS in your local.conf to redirect the SRC_URI request to one of your "somewhere else" repo? Mar 29 12:39:14 zbodek: but indeed, FILESEXTRAPATHS does nto seem to be an appropriate mechanism since you need to know where the layer with the .inc file is located ont he FS and it's not guaranteed to be stable over time Mar 29 12:42:48 qschulz do you by any chance have a suggestion or pointer on how to build 3 packages from the same git repo. I'm also good if it just generates one yocto package, but being a python n00b I do not really know how to tackle this Mar 29 12:44:52 actually the way I build now each package gets an __init__.py at top level but they are identical Mar 29 12:59:59 eFfeM1: rburton suggested something, have you tried that already? Mar 29 13:03:52 if they're writing the same file then you'll need to understand any dependencies and sort out the packaging Mar 29 13:04:01 as you're not showing us the source, it's hard to help Mar 29 13:08:57 rburton I have this: Mar 29 13:09:00 do_compile() { Mar 29 13:09:00         DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-client; distutils3_do_compile Mar 29 13:09:01         DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-choreography-client; distutils3_do_compile Mar 29 13:09:01         DISTUTILS_SETUP_PATH=${S}/git/python/bosdyn-mission; distutils3_do_compile Mar 29 13:09:02 } Mar 29 13:09:17 oops, I see something Mar 29 13:11:05 the git part should not be there as it is part of #{S}; hovever without it, it also tries to find setup.py in ${S} Mar 29 13:11:21 I also tried without the ;  but saem result Mar 29 13:11:57 ...python3-bosdyn-sdk/2.3.3-r0/git//setup.py': [Errno 2] No such file or directory Mar 29 13:13:26 why dont' you just do separate recipes for client, mission and choroegograph, and let -core ship the top-level bosdyn/__init__ Mar 29 13:13:33 (deleting it from the other recipes) Mar 29 13:14:52 rburton that seems the simplest solution, I have the 3 recipes already but need to see how to best get rid of the __init__py file in the other recipes Mar 29 13:15:20 do_install_append() { rm ${D}/${libdir}/python*/bosdyn/__init__.py} Mar 29 13:15:36 eFfeM1: It seems my problem can be resolved by adding FILESEXTRAPATHS_prepend := "${THISDIR}/files:" to the inc file that pulls the patch. thank's for your help anyway Mar 29 13:16:38 rburton guess I need to make sure that the one with the __init__.py is installed last Mar 29 13:17:04 zbodek you're welcome, glad to be of help Mar 29 13:34:46 rburton the rm is a good plan, your snippet was missing the site-packages part in the path but that was easy to fix, now still seeing how to get them installed in the right order as indeed the one with the __init__ must be last; but they are not processed in the order as they appear in IMAGE_INSTALL, seems they are sorted Mar 29 13:34:47 I'm now trying to have the recipe with the __init__ to have an RDEPENDS on the other two Mar 29 13:39:27 that does not work either, as they are sorted I either need to get rid of the __init__.py in the package, for now I am considering just to stuff the __init__.py file in the dbg package or so Mar 29 13:46:59 rburton in the end I did this in two packages and that solved the issue: Mar 29 13:47:00 FILES_${PN}-dbg += "${libdir}/python*/site-packages/bosdyn/__init__.py" Mar 29 13:47:08 will probably make it a separate package Mar 29 13:47:24 anyyway I now can proceed. Mar 29 13:48:00 rburton qschulz abelloni thanks for your help! Mar 29 14:03:46 eFfeM1: why do they need to be installed in a particular order? just putting the init in the -dbg package is *horrible* Mar 29 14:23:24 Hi all - I'm a Yocto newbie and just have my first build (Gatesgarth core-image-minimal) running on my target hardware (intel x86-64). For the next step, I'd like to add Nvidia GPU drivers, but I have not found much information. This seems like it would be a relatively common use-case, so I'm curious if I have the wrong idea here. Mar 29 14:23:28 I found an old mailing list thread about this but it seemed to die off without resolution: https://www.yoctoproject.org/pipermail/yocto/2018-October/042982.html Mar 29 14:51:39 aganders3: you probably need the nouveau kernel driver to be compiled by the kernel recipe either built in or as a module and have mesa packages installed Mar 29 14:52:33 maybe some additional X packages too Mar 29 14:52:39 qschulz: thanks! Unfortunately my primary use (headless system) is CUDA, which I don't think the nouveau driver supports. Mar 29 14:54:10 I noticed there is a gentoo ebuild for these drivers (https://gitweb.gentoo.org/repo/gentoo.git/tree/x11-drivers/nvidia-drivers/nvidia-drivers-450.102.04.ebuild), maybe that would be a good starting point for creating a bitbake recipe? Mar 29 14:57:34 aganders3: is there a reason for going with Yocto for this build and not, e.g. gentoo or other distros? Mar 29 15:00:07 Maybe it's the wrong direction. We're using Ubuntu now and having trouble managing updates in the field (kind of an IoT-like setup). I've been looking at projects like RAUC and SWupdate to enable atomic updates, and that led me to looking into Yocto. Mar 29 15:00:40 We're in kind of a weird space I feel where we have a headless system with basically desktop-class hardware, but we want to treat it a lot like an embedded system. Mar 29 15:20:15 Hey folks, could you help me out on this one? Mar 29 15:20:18 https://stackoverflow.com/questions/66834542/append-variable-does-not-update-kernel-command-line?noredirect=1#comment118172990_66834542 Mar 29 15:20:44 I'm trying to set the `APPEND` variable to set `isolcpus=2` for the kernel cmdline. Mar 29 15:21:51 I just added a dedicated machine config named `raspberrypi4-custom.conf` within which I then added `APPEND...` and override MACHINE back to `raspberrypi4` to not break any other dependencies Mar 29 15:22:18 Still, my `/proc/cmdline` does not include the `isolcpus` statement. I'm a bit puzzled how to do that Mar 29 15:22:33 emrius: kernel parameters are set via a config.txt file on the boot partition on RPi IIRC Mar 29 15:23:27 I thought that was just one out of several options? Do I *have* to do that via conig.txt on RPis? Mar 29 15:26:12 emrius: bootloader is board specific. RPi has its own weird bootloader. By default, this weird bootloader is used and it uses config.txt (at least in *MANY* distros, don't remember for Yocto). Mar 29 15:27:49 qschulz: Okay, thanks. But also are you sure about `config.txt`? I tried that on an already bitbaked image and it doesn't work either. Or does the flag have to be present at compile time? Mar 29 15:28:10 emrius: otherwise, you have bootargs in U-Boot if it's used, but needs to be put into U-Boot environment which can be done in several ways Mar 29 15:28:40 emrius: config.txt is a txt file, so no, no need for it to be done at compile time if you just want to play with it Mar 29 15:29:45 qschulz: Okay, then it doesnt work through config.txt. Or works through `/uboot/cmdline.txt` though. But, I felt that the `APPEND` variable was just so much more convenient. (If it worked) Mar 29 15:32:43 ... and I'm still a bit puzzled. I mean technically that sounds like the right approach right? cf C.1.6. at the veeeeery bottom here https://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html Mar 29 15:43:20 emrius: it appears nowhere in poky thud (2.6), so it was maybe removed and forgotten in the docs? Mar 29 15:43:56 emrius: oh geez Mar 29 15:44:25 qschulz: ah hm... maybe. Tried to tackle that with grep but didn't really come to a conclusion. Mar 29 15:45:34 Well, then I'm happy that I could contribute to keeping the documentation up to date :) Mar 29 15:45:43 When can I patch the docs? Mar 29 15:49:02 emrius: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=136d9cd07d1c2ad316cd59b8fd95b772698e1be2 Mar 29 15:49:15 it is OLD Mar 29 15:50:40 emrius: for 2.5, check if there's someone willing to take patches but I would say you won't get approval Mar 29 15:50:44 emrius: otherwise: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ Mar 29 15:51:48 qschulz: Ok thanks Mar 29 15:52:22 I would say it makes sense to remove it since I don't think there's any way to formulate it well enough to list all possible cases Mar 29 16:16:19 Is there a way to get the output uboot env variables generated by yocto (without running u-boot since we don't get any output)? Mar 29 16:22:35 alex88: a few env variables are actually set at runtime by U-Boot itself so it wouldn't be complete anyway Mar 29 16:26:37 qschulz, ok so it's better to rely on UBOOT_* checked with bitbake -e? Mar 29 16:27:00 alex88: which u-boot env variables are you talking about? Mar 29 16:29:24 qschulz, basically we have a device that doesn't show anything in the serial console (while with the original SD card from the manufacturer it does) so I'm just trying to compare the u-boot configuration (somehow) to see what can be wrong Mar 29 16:30:15 I've been told the dtb might be wrong but the dtb is in the rootfs partition so it should be something that's used after u-boot loaded right? Mar 29 16:31:00 alex88: there's dtb support in U-Boot too and U-Boot has its own dtb, separate from the kernel;s Mar 29 16:33:28 qschulz, oh ok, because right know what I've done is, took the dtb from the manufacturer SD card, converted to dts with dtc, added it to the kernel using a custom recipe by modifying SRC_URI and setting KERNEL_DEVICETREE to the custom dtb name and that correctly outputs the dtb in the deploy dir Mar 29 16:33:48 alex88: the u-boot environment will be for sure accessible at runtime but since I guess you have nothing on serial, it won't help much. If it;s a configuration issue, menuconfig and include/configs/yourboard.h as well as board///*.c would help you figure out things probably Mar 29 16:34:11 so this only adds the dtb to the kernel and not u-boot? Mar 29 16:34:23 alex88: yeah no, they are different device trees, with potentially different properties/syntaxes/nodes, etc... Mar 29 16:34:57 alex88: don't recompile a decompiled dtb, just put the dtb as is in the install step Mar 29 16:35:13 oh ok, so the dtb I took in rootfs/boot is only for the kernel, I should get the one used in u-boot which without manufacturer support will be hard I imagine Mar 29 16:35:42 oh ok will do that Mar 29 16:35:44 alex88: some old U-Boot don't have dtb support Mar 29 16:35:52 I mean, for configuring itself Mar 29 16:36:23 the one they use is 2014.07 and it contains a fdtfile variable that points to the device dtb filename https://gist.github.com/alex88/5e8d604ab15540b84353040a83bc0606 Mar 29 16:38:36 alex88: you're in for a treat with such an old u-boot :) Mar 29 16:39:21 qschulz, at least that one is working :) Mar 29 16:40:18 alex88: the file you send very much looks like a file used to setup the environment and you also have uEnv.txt support probably seeing it being mentioned Mar 29 16:41:11 the sd card they provide doesn't contain uEnv.txt, that file is the output of the printenv command run from u-boot Mar 29 16:43:05 so, without a dtb for u-boot, is it hard to achieve a working u-boot? we're also considering getting a consultant do it but since we're doing this as a favor for a customer that has hundreds of these useless devices we can't invest week of development, we will rather have the customer buy another hardware with an available bsp layer Mar 29 16:43:22 *weeks Mar 29 16:43:53 WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400' Mar 29 16:43:55 alex88: what exactly are you trying to achieve? Mar 29 16:44:24 getting a bunch of them in what is probably about a month old(ish?) build directory. Mar 29 16:48:23 alex88: since it seems you have a working U-Boot from your vendor and don't have much time to spend :) Mar 29 16:49:13 alex88: anyway, you might receive more help on #u-boot IRC channel, but porting your board support to a new U-Boot is probably not a one week thing Mar 29 16:49:48 qschulz, get a minimal image (created via yocto) to boot on the device.. yes we have the working u-boot from the vendor. I've also tried to just replace the rootfs but it hangs on "starting kernel" Mar 29 16:50:12 qschulz, last question, the make menuconfig should be run where? Mar 29 16:50:56 qschulz, if it's that hard we won't even bother doing it, my boss said to not spend more than a day, I was ok doing more for free just for fun but not weeks for sure :) Mar 29 16:51:14 alex88: if you replaced the rootfs but you reach only Starting kernel it's probably that your rootfs overrode the place in RAM where you kernel was loaded by U-Boot (I guess you went for an initramfs?) Mar 29 16:51:41 alex88: root of U-Boot git repo after having sourced the correct defconfig Mar 29 16:52:11 alex88: shameless plug: https://www.youtube.com/watch?v=5E0sdYkvq-Q Mar 29 16:52:24 at least for the abstract steps and some explanations Mar 29 16:52:43 ok thank you, regarding initramfs I think I'll have to read more about it, not sure what you mean :) I've just tried to use the am335x-evm config that meta-ti provides Mar 29 16:52:55 thanks a lot for the link, at least I'll get more context Mar 29 16:57:09 alex88: welcome to the wonderful world of vendor BSPs of very varying quality (more often bad than good unfortunately) Mar 29 17:00:25 Definitely not a fun experience so far, but very interesting and lots to learn :) Mar 29 17:04:04 Hi, I am looking to get some training with board bringup, u-boot and kernel configuration for Xilinx FPGA boards. Ideally this would be 1 on 1 sessions via zoom. Does anybody have recommendations for who can offer these services? Thanks! Mar 29 17:04:54 is there a well known brand that makes industrial devices that have good compatibility with yocto? or should I just go in the machines list in the openembedded site? Mar 29 17:15:58 If I would like to have a SDK to be able to develop on a platform that has glibc 2.19 and I can't upgrade it, do I have to absolute use the `daisy` release? Mar 29 17:22:00 hi everyone! o/ Mar 29 17:44:06 alex88: most manufactureres of SoC and SoM's make "industrial grade" versions Mar 29 17:56:33 malinus, I mean complete devices (with enclosure and I/O) not just SoC/SoM.. as I imagine having a compatible SoC isn't enough to get a working image OOB (but I might be wrong) Mar 29 18:06:09 I never heard SoM before Mar 29 18:07:15 Since I've started playing with yocto I had to look up most of the words :) Mar 29 18:17:47 alex88: you mentioned your board was from another manufacturer based on TI am335x SoC - did you get BSP sources and build instructions from that manufacturer? or are you trying to straight load TI referencce BSP from meta-ti? Mar 29 18:19:06 alex88: as discussed above, devicetree would be the biggest difference to get a custom board up and running, especially if your manufacturer didn't follow the TI reference closely Mar 29 18:21:33 alex88: from the Yocto perspective, you get all the vendor BSPs here for their SoCs and their reference and evaluation platforms, like EVMs, EVks, etc. Mar 29 18:21:44 denix, the latter (which isn't obviously so simple), unfortunately the manufacturer doesn't have public BSP for that (they have it since they use yocto too but they want us to use their OS) Mar 29 18:23:27 denix, by vendor you mean like meta-ti for TI devices? because TI is the one doing the SoC and someone like (e.g. beaglebone) is putting the soc on a board? sorry I'm a bit confused as you can tell :) Mar 29 18:23:37 RP, any idea if poky 64662290d3 / bb d978e7b35 is still an issue 9 years on? I spotted the double slash in alternates and went data mining to see where it came from... Mar 29 18:23:47 alex88: if a 3rd-party manufacturer does a custom board with enough differences from reference, they need to provide a modified BSP for that board. or at least instructions Mar 29 18:25:31 denix, it can very possibly be that I'm just not able to correctly use yocto myself, as on top of meta-ti am335x-evm the only thing I've done was to get the dtb in the kernel (but probably not in uboot at this point) Mar 29 18:27:03 alex88: well, in your case TI is an SoC vendor. they also provide so called evaluation boards (EVM). so TI BSP officially supports own SoCs and EVMs. they you also have a different vendor who designed own board with TI SoC, so if it's too different from TI EVM, you can't straight up load TI BSP on that board - need to change configs and devicetrees, etc. Mar 29 18:30:29 alex88: I'm not trying to say you'd need a completely new BSP - TI BSP (kernel, u-boot, firmwares) probably covers most if not all of that custom board of yours. but you still need to configure it properly for that board Mar 29 18:32:04 denix, I'll check the board to see if it's similar to the evm.. I just hoped, having a working OS image, that I could somehow find the configuration changes needed to get it to work with our own yocto image Mar 29 18:33:08 the other option would be to find a complete product (not just a board) with an available BSP so we can skip all the work needed to get it to boot and focus on the actual OS contents Mar 29 18:35:08 alex88: do you get any decent documentation with the board, besides just the binary images? Mar 29 18:36:59 denix, not really, it's a complete device with an enclosure not a board so they only provide documentation about the I/O and how to use it with their software Mar 29 18:40:04 alex88: do you need to customize u-boot? can you simply use their u-boot binary and load own kernel and rootfs? Mar 29 18:42:15 denix, that's definitely an option, but when I've tried it was first complaining about not finding /boot/zImage then I've formatted the partition using "-O ^metadata_csum,^64bit" and it was able to get to the "Starting kernel" point and then it was stuck Mar 29 18:42:56 but maybe that's because of initramfs as qschulz mentioned (which I have to understand better) Mar 29 18:43:14 (stuck and restarting after a while) Mar 29 18:43:25 alex88: I don't know if it's possible to re-create necessary board///*.c and corresponding dts files from the binary image of u-boot Mar 29 18:44:40 alex88: check if the right uart is used for the console output to see kernel messages Mar 29 18:47:45 the board///*.c files are for uboot? Mar 29 18:48:02 denix, ok I'll look into how to change the UART, thank you! Mar 29 18:49:56 becuase in my case the machine I use (am335x-evm from meta-ti) already sets the serial consoles with SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS3" and that matches what I see in the working SD uboot env Mar 29 18:54:20 alex88: yeah, IIRC ttyS0 is used for GP am335 and ttyS3 was added for ICE industrial variant Mar 29 18:55:09 this is what I see in the working SD kernel log https://gist.github.com/alex88/8dad9739f758b22581c1f5e8de15b067 Mar 29 18:55:40 so the serial port seems to be correct Mar 29 18:57:34 alex88: can you check what bootargs are passed to the kernel in the working logs? Mar 29 18:58:49 could be the bootargs env variable from their u-boot? Mar 29 18:58:52 bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait Mar 29 19:17:32 what would be a good way to build qt 5.12 with gatesgarth? Get meta-qt gatesgarth then make appends in my layer? Mar 29 19:24:00 hey everyone. Does anybody have experience with bringing up any NXP layerscape boards? I can get along fine enough (still very new to me) with the qemu targets, but am struggling with bringing up the "real" board. Mar 29 19:44:39 samw: SoM is System On Module. It's what you usually run with when you don't want to make your own carrier board for the SoC. Kinda like the rpi zero. Mar 29 19:45:22 alex88: usually manufactureres provide working yocto Mar 29 19:46:40 malinus, unfortunately that's not possible in our scenario Mar 29 19:46:53 how so? Mar 29 19:48:34 alex88: you might want to pressure your board manufacturer to release sources to meet GPL obligations... Mar 29 19:52:42 is that somehow mandatory? Mar 29 19:52:58 malinus: they got a custom board/product with binaries only (and those are quite old). the manufacturer used TI SoC in the board, but TI BSP won't boot on the board. no sources or instructions Mar 29 19:53:51 h-how did they end up in that situation? Mar 29 19:54:01 alex88: GPL license does require sources to be available on request Mar 29 19:55:12 denix, what's under the GPL license that will give me the right to ask them for sources? Mar 29 19:56:27 The Linux kernel and busybox, for example. Mar 29 19:56:49 as well as u-boot Mar 29 19:57:19 so theoretically just by using u-boot/busybox in their OS they would have to provide the meta layer used to build the image? Mar 29 19:58:15 I have found the NXP docs extremely lacking. I've spoken with a few reps from them and they are strongly pushing their LSDK over continuing to support yocto Mar 29 19:58:38 hi! one of the recipes a layer here uses SRC_URI_append_machineX and SRC_URI_append_machineY. when i run "devtool modify ", it applies patches from both SRC_URI_append_machineX and SRC_URI_append_machineY. Mar 29 19:58:49 bug? feature? :> Mar 29 20:01:26 alex88: not sure about the yocto layer, as metadata is usually MIT licensed. but at least you can (in theory) get kernel and u-boot soures and peek into necessary configuration and devicetree Mar 29 20:02:20 strictly speaking they don't even have to provide kernel configs nor devicetree files Mar 29 20:02:23 just the plain sources Mar 29 20:03:04 alex88: those will be 7-year old code bases, of course... Mar 29 20:03:29 at this point it's probably easier to find a device alternative Mar 29 20:03:57 I mean, it's not us those with hundreds of bricks so there's no way we can get the investment back by fixing it Mar 29 20:04:56 anyway, thank you very much denix for helping! Mar 29 20:06:51 derRichard: just the plain sources can get enough info, like u-boot board config, etc. but yeah, it may not be straighforward anyway and require extra work on alex88 part... Mar 29 20:07:06 alex88: you are certainly welcome! Mar 29 20:08:35 paulg: I have no idea to be honest Mar 29 20:10:30 RP, ok, I guess I'll either just ignore the // or investigate further "someday"... Mar 29 20:11:21 paulg: I reported it, worked around it, moved on... Mar 29 20:11:32 :) Mar 29 20:28:24 derRichard: that's not a bug per se, but it is supposed to apply them to different branches (creating one per separate configuration) - does it do that? Mar 29 20:34:43 bluelightning: it creates also one combined branch, for whatever reasons. just found that i can stop it from doing so by passing --no-overrides to it Mar 29 20:40:09 What is the preferred tool for a python recipe? setuptools? Mar 29 20:53:07 I see that pyproject.toml is somehow the new thing for packaging python apps. But meta-python use a lot of setuptools3, I guess it's still the preferred (yocto) way Mar 29 21:06:59 vdl: moto-timo mentioned on last week's technical call that he's working on a transition Mar 29 21:08:27 smurray: in the meantime, it's better if I add a setup.py file and use Mar 29 21:08:33 setuptools3, right? Mar 29 21:09:04 (until a new yocto release switches to pyproject.toml Mar 29 21:09:07 ) Mar 29 21:10:51 vdl: setuptools3 is what is supported today AFAIK Mar 29 21:11:49 vdl: moto-timo may pop on at some point and be able to describe his plans Mar 29 21:12:26 I'll stick with setup.py/setuptools3 for now then. Mar 29 21:25:41 feel free to write a class for the toml stuff Mar 29 21:25:52 the sooner someone starts a class the sooner its supported Mar 29 21:29:44 vdl: I suspect someone will write a class and then we'll migrate over as newer releases come out as we're doing with meson for example Mar 29 21:32:14 vdl: isn't setuptools mostly merged into distutils these days? Mar 29 21:32:22 i admit i don't use it that heavoy Mar 29 21:32:26 erm, heavily Mar 29 21:39:27 hey guys what is the most reliable distro for yocto? I'm having troubles on manjaro as my host. I want to pull a docker image and build there Mar 29 21:40:06 they say ubuntu is the most stable one but which version? Mar 29 21:40:11 savolla, I had good luck with Ubuntu 18.04 Mar 29 21:40:18 oh thanks! Mar 29 21:40:18 depends on the poky version you want Mar 29 21:40:35 felix_inst: I want to build for bbb Mar 29 21:40:56 this is my first experience with yocto Mar 29 21:41:03 savolla, I used 18.04 with zeus. 20.04 would not work. dunfell may be the other way around Mar 29 21:41:32 zeus and dunfell. they are yocto releases right? Mar 29 21:42:10 branches sorry Mar 29 21:42:29 savolla: also look at pyrex Mar 29 21:42:32 zeus is 3.0.x Mar 29 21:43:17 https://github.com/garmin/pyrex Mar 29 21:43:24 dunfell appears to be 3.1.x Mar 29 21:43:42 guys I really don't understand the yocto terminology yet. those are yocto branches? which we specify with -b option while cloning? Mar 29 21:44:14 the last argument is the branch. the -b flag just makes you create a local branch at checkout Mar 29 21:44:17 it's a git thing Mar 29 21:45:05 I looked at yocto reference but it is very long and I don't have the time at the moment. but deffinitely will read the manual later. maybe you guys can guide me to build a minimal image for bbb Mar 29 21:46:03 savolla, I am pretty much in the same boat. So I don't know how to help you there. I would imaging BBB has a quickstart tutorial Mar 29 21:52:46 savolla: dunfell 3.1 is the current yocto LTS release. many yocto layers have separate branches specific to the release. https://wiki.yoctoproject.org/wiki/Releases Mar 29 21:53:11 thanks anyway felix_inst . I also need to make a Qt application for bbb which displays some sensor information. I tryed to cross compile my application with qtcreator but didn't work. so someone told me that I need to create an image with yocto first. I really don't know if this is true. I'm asking you guys now Mar 29 21:53:30 denix: oh thank you! Mar 29 21:53:36 I get it now Mar 29 21:58:37 savolla, there is a qt layer - and you should be able to generate the cross compiler toolchain after the main build Mar 29 22:05:14 felix_inst: really? that is really cool then.. where can I get that layer? Mar 29 22:06:27 I just started with yocto and watching this tutorial https://www.youtube.com/watch?v=MKpLQ2bGsAk . sorry for my annoying questions again Mar 29 22:09:57 savolla, I have not used it myself, so take it with a grain of salt. This is the layer I *think* might be useful: https://github.com/meta-qt5/meta-qt5 Mar 29 22:11:33 felix_inst: thank you so much! I'll definitely try it. Mar 29 22:12:03 savolla, yw, I hope that's what you need Mar 29 22:17:16 savolla you will need to pull in meta-qt build your app. The recipe should include inherit qmake5 if you are using qmake. You can then also build the SDK which you can integrate with qt creator to cross compile and deploy to your machine Mar 29 22:19:53 renegade: yeah this is exactly what I was planning for :) thank you Mar 29 22:32:49 vdl: smurray: oe-core currently only supports setuptools and distutils. When we last started looking at new packaging methods, upstream wasn't ready yet. I forget the details. It's worth another look, but any new bbclass should really be landing in oe-core first IMHO. Mar 29 22:34:21 vdl: smurray: I'm more interested in a common ptest-pytest class for my own development at the moment. **** ENDING LOGGING AT Tue Mar 30 02:59:56 2021