**** BEGIN LOGGING AT Tue May 11 02:59:57 2021 May 11 06:46:57 Hello May 11 06:47:54 Any recommandations for a lightweight browser to add to my image? For ARM7 BSP thanks May 11 07:26:16 I hve something very weird, bitbake fails with: May 11 07:26:16 Your Python 3 is not a full install. Please install the module distutils.sysconfig (see the Getting Started guide for further information). May 11 07:26:17 However if I type May 11 07:26:18 python May 11 07:26:27 import distutils.sysconfig May 11 07:26:35 on the command line I get no error May 11 07:28:18 but sanity.bbclass does roughly the same: May 11 07:28:19     try: May 11 07:28:20         import xml.parsers.expat May 11 07:28:20         import distutils.sysconfig May 11 07:28:21     except ImportError as e: May 11 07:28:21         status.addresult('Your Python 3 is not a full install. Please install the module %s (see the Getting Started guide for further information).\n' % e.name) May 11 07:28:52 anyone an idea why bitbake cannot find distutils.sysconfig  whereas as a user I can import it May 11 07:28:58 could this e.g. be pseudo related? May 11 07:29:30 (btw this only happens in our CI system not on a local build) May 11 07:40:09 is your CI env the same as local? I.e. have you containerised? May 11 07:42:01 dp local and in CI it is running in a docker based on the same Dockerfile, however the CI has some TeamCity scripting around it May 11 07:43:16 actually it used to work in CI until I did a minor change in the docker file (I additionally installed pigz); guess that triggered the sanity checker) May 11 07:43:32 my current hunch is that it is related to python versions May 11 08:03:58 eFfeM1: Do you add buildtools to your container? Just install these and you have everything you need -> https://docs.yoctoproject.org/singleindex.html#installing-a-pre-built-buildtools-tarball-with-install-buildtools-script May 11 08:05:16 resoum I'm not sure, will check, actually I inherited most of this; thanks for the link May 11 08:13:10 ok, got it, it is indeed a python/python3 issue May 11 09:11:08 Hi. Its been a while since I used yocto (last time was dunfell release), but when I try to run bitbake nowadays in hardknott I get "Timeout while waiting for a reply from the bitbake server (60s)". Anyone know what I'm missing ? May 11 09:12:51 Has starting a bitbake server become mandatory in the latest releases ? May 11 09:59:13 morning, has anyone got a recommandation for a lightweight browser I can add to my image as Chromium takes more than 10 seconds to start, the processor on the embedded is ARM7 (imx6ul) ... thanks May 11 10:12:00 patrick_r: last time I tried with dillo, it's much lighter... but then much less functionnal with many sites, so I just changed plans and did not embark a browser :) May 11 10:13:09 @yann: it only needs to display help pages (very basic html) do you know where I can find the recipe for that? May 11 10:13:36 look in the Layer Index May 11 10:13:47 https://layers.openembedded.org/layerindex/ May 11 10:14:58 patrick_r: oh, maybe my last try was with epiphany in fact, that one is on meta-oe May 11 10:15:20 probably used dillo on some armbian derivative May 11 10:17:45 @yann: no match for dillo May 11 10:17:58 @yann: in meta-oe May 11 10:18:26 <_dleppich> Hi, I have a yocto system where some applications come via sd card to the final system. They are already compiled against an older library (libssl.so.1.0.0). The yocto system got updated and has the libssl.so.1.1 present. I found an interesting passage in the mega manual, but the relevant details for me are missing: May 11 10:18:28 <_dleppich> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#migration-2.6-openssl-changes. Does someone know how to solve this issue? May 11 10:18:37 yeah, that's in meta-webstuff - that's how I know I did not use that one in the end :D May 11 10:18:54 <_dleppich> I don't have the possibility to recompile the issue causing applications May 11 10:19:13 patrick_r: search for "browser" in the recipes index and make your own choice :) May 11 10:56:31 _dleppich: add openssl1.0 to your image. May 11 10:56:45 you'll need to copy the recipe from an old release May 11 10:57:20 also, shout at the people you're presumably paying to provide those binaries that use the old openssl and ask for updated builds, or sources. May 11 11:01:28 <_dleppich> rburton: Thanks. I found an old version of openssl in a separate layer. I explicitly chose the old version with PREFERRED_VERSION_openssl = "1.0.%". Rebuilding the image resulted in many packages being rebuild with the older version of openssl. That did not surprise me. Unfortunately, one of my packages is incompatible with the old version of openssl. This might be fixable. But isn't it possible to May 11 11:01:29 <_dleppich> install the libssl.so.1.0.0 in addition to the new openssl version 1.1 to the image? I just want to have the runtime library for compatibility issues and use the newer version for all my yocto build recipes. May 11 11:02:08 iirc openssl isn't parallell installable May 11 11:02:23 there is a openssl1.0 layer which i guess you found May 11 11:02:27 (i'd forgotten about that) May 11 11:03:12 <_dleppich> I found this one: meta-openssl102 (https://git.yoctoproject.org/git/meta-openssl102) May 11 11:03:33 <_dleppich> I'm currently trying to just copy May 11 11:03:46 @yann: trying epiphany now hopefully iut launches a lot faster May 11 11:03:49 <_dleppich> the libssl.so.1.0.2 to the target rootfs to /usr/lib. May 11 11:35:49 _dleppich: you can take the recipe from meta-openssl102 but you need to rename it in order to have both libssl1.0 and libssl1.1 on your system May 11 11:35:54 otherwise only one is usable May 11 11:36:20 and I'm pretty sure you want to use openssl1.1 wherever possible and not migrate your whole system to openssl1.0 just because of one piece of SW May 11 11:37:17 there was some time ago an openssl10 in oe-core if I remember correctly May 11 11:37:23 or poky May 11 11:37:34 <_dleppich> rburton: I tried copying the libssl.so.1.0.2 from the build/tmp/work/.../boost/1.0.2/.../image/usr/lib/ to the target rootfs. It does not complain about ssl anymore, but now about boost being in the wrong version. May 11 11:38:02 anyway, at one point in time they coexisted, so take this one and upgrade the recipe to what;s currently in meta-openssl102 May 11 11:39:07 <_dleppich> qschulz: You are totally right. This is not the solution to go and I think we will get access to the application source code soon. Meanwhile I wanted to make it work in order to check, if openssl is the only issue the application might have after the updated system. May 11 11:39:29 _dleppich: objdump -x on your prebuilt binary/shlib and every lib starting with NEEDED, if it ends with a versioned number instead of just .so, you either need to use patchelf to modify it or build the appropritate recipes, by backporting them or porting them May 11 11:40:20 <_dleppich> qschulz: Thanks! I think this was what I was trying to find out with a way worse approach! May 11 11:56:03 khem RP: any idea why gcc -print-libgcc-file-name is outputting just a filename and not a full path? May 11 12:36:55 rburton: no :/ May 11 12:58:34 I blame khem May 11 13:13:31 Was wondering if anyone could give me the best approach to eliminate all games from matchbox desktop? May 11 13:37:04 kanavin: I've realised why we had tha avahi split. "bitbake ghostscript" needs ghostscript -> cups -> avahi -> gtk3+ :/ May 11 13:38:06 RP: if it's only a build time dependency, is that problematic? May 11 13:38:23 kanavin: badly hurts build performance :( May 11 13:39:01 RP: right, the split was ugly though :( May 11 13:39:22 kanavin: so is the gtk3+ dependency in the chain like this :/ May 11 13:39:31 RP: is disabling the gtk bits in avahi an option perhaps? May 11 13:40:24 * zeddii finds himself wishing for a wildcard on include/require, even though it makes so little sense May 11 13:40:27 kanavin: I don't know. I just had a "what is the build doing?" moment trying to do what I thought was a quick test May 11 13:43:22 RP: I can quickly make a patch; if there's grumble about needing the gtk items, we can figure out some way to restore them in a separate recipe. May 11 13:43:37 rburton: do you remember what the gtk bits do? May 11 13:46:31 RP: I quickly checked, it's a library (not an executable) that provides a gtk dialog for browsing services May 11 13:48:15 kanavin, RP, rburton: It's the avahi-discover GUI program, as well as a tool to specifically ssh or vnc into a device with a mDNS service May 11 13:48:48 RP: I can try to disable and see if anything breaks, particularly in meta-oe May 11 13:48:49 bssh and bvnc are the respective browsing programs if you are curious May 11 13:54:08 JPEW, kanavin: does it disable the discover program or just the dialog? May 11 13:54:23 if the latter I suspect we're ok, if it disables the whole thing, that wouldn't be good May 11 13:58:14 RP: disables all May 11 13:58:20 kanavin: RP: disabling the gtk bits of avahi is entirely worth doing May 11 13:58:35 (i actually have a partial rewrite of the avahi recipe that does that) May 11 13:58:58 rburton, if it were just the binaries I'd agree, but there's also a library, and I'm sure there's some obscure recipe in meta-oe that uses it :-/ May 11 13:59:07 bah May 11 13:59:26 unless that too can be configured optional May 11 13:59:56 kanavin: I think this is why we did the split :/ May 11 14:00:02 yes May 11 14:00:03 it is May 11 14:07:54 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/3415/steps/14/logs/stdio - so helpful :/ May 11 14:30:15 I'm about to get distracted for a while. http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=7e64c4126193262cb0233a295659cb7b3b288738 has 8 uninvestiagted CVEs on the bottom which we need to sort to complete an audit of the ones listed against master May 11 16:01:15 RP, rburton I sent patches to disable gtk in avahi. The only affected item is remmina, which I think it ok. May 11 16:16:03 Hi all, is it possible to remove some option set in a recipe ? I would like to remove some option of a EXTRA_OEMAKE variable from a .bbappend :)  Thx May 11 16:16:16 EXTRA_OEMAKE_remove = "the option" May 11 16:16:26 Ninic0c0: override EXTRA_OEMAKE or do what rburton suggested May 11 16:16:38 but remember that _remove are final, you can't unremove stuff May 11 16:16:47 s/are/is May 11 16:17:18 rburton qschulz thx guys i will make a try :) May 11 16:27:35 fray, how'd you suggest to go from a plain yocto + meta-xilinx (for zcu104-zynqmp) to a bootable SD image? is there a specific reason you don't have example wic files in meta-xilinx-bsp? May 11 16:28:30 work is in progress, but the official way of doing it is to use hte petalinux front end for all of that. Once you have a petalinux configuration, capture it and you can use it to generate Yocto Project builds. It's not ideal for YP people, but that's the current process.. May 11 16:29:38 We (yocto project team) are actively working to make a Yocto Project only flow possible. It can be done, but it's not as easy as the petalinux flow. Partially because some of the BSP knowledge isn't available on the YP side of things at this point. May 11 16:29:57 (I have no time frame for when.. it's just being worked on) May 11 16:30:43 ask the Yocto kernel maintainer for help; I hear he has ooodles of free time. May 11 16:31:10 lol May 11 16:31:36 unfortunatly kernel isn't the issue.. :P it's the FSBL, u-boot, disk configuration, etc.. all the stuff that runs BEFORE linux May 11 16:32:16 fray, so the FSBL stuff is missing for the eval kits in meta-xilinx? May 11 16:33:21 https://www.openembedded.org/wiki/OEDVM_2021 May 11 16:33:28 you need vivado configuration(s), XSCT (meta-xilinx-tools) to generate the fsbl and pmu-firmware specific to your board. Currently there is no way to build a standalone fsbl, but there is an experimental way for building a pmu-firmware (generic) May 11 16:33:42 my immediate target is just to have a working linux, no bitstream yet :) May 11 16:34:04 Most of the people I know of doing YP work, build the stuff before Linux 'elsewhere', and just use it.. then they focus on the Linux kernel and userspace for their regular YP builds May 11 16:34:27 meta-xilinx-tools provides all you need May 11 16:34:39 You have to have a bitstream to boot. The SoC itself won't do anything w/o a minimal bitstream. Each boards confgiuration affects teh bitstream, which affects the FSBL and PMU-firmware May 11 16:35:01 fray, hmm :/ I'd prefer having all the software artifacts fixed and repoducible in my bsp layer May 11 16:35:12 meta-xilinx-tools provides the tooling, but you still need the xsa file for the board in order to generate it with XSCT (part of meta-xilinx-tools) May 11 16:35:27 ok May 11 16:35:49 shoragan I understand, but the reality is things are too tightly coupled to Vivado/XSCT and PetaLinux at this point. It's being worked on, really. We've made huge improvements over the last year.. but we've still got a ways to go. May 11 16:36:22 fray, don't misunderstand me, i'm not trying to complain :) May 11 16:36:26 The expectation is (eventually) your hardware team can pass to you an XSA file (board configuration) and then everything else will just run from within the Yocto Project side, not requiring vivado/xsct or petalinux.. May 11 16:36:33 fyi: https://lgtm.com/projects/g/openembedded/bitbake/?mode=list May 11 16:36:34 i know it's lots of moving parts May 11 16:37:33 One of the things we're moving toward is using multiconfigs to build the various parts and pieces that run 'before Linux'.. but it's requiring a lot fo infrastructure wiring and changes to the handoff from Vivado May 11 16:38:27 we're not sure if this lgtm site is reporting actual problems but someone (armpit) may look the issues found it and report back later. May 11 16:39:05 (under the hood what is happening now is something like vivado -> petalinux -> yocto project -> xsct (vivado) -> yocto project -> petalinux... circular build steps are part of the problems) May 11 16:42:03 fray, would it make sense to have a prebuild bitstream+FSBL for the eval boards in meta-xilinx? May 11 16:42:33 so you could at least boot something without vivado? May 11 16:44:31 shoragan there are licensing issues with binaries and similar. PetaLinux solves this by requiring EULA and other sign-in stuff.. unfortunately not my choice May 11 16:44:39 ouch May 11 16:44:54 ok, thanks for the quick response! :) May 11 16:45:23 on both the bitstream side and the software side various components may come from different providers.. (may), I don't have specifics for the zcu104 board, but I know various configurations have different license requirements unfortunately May 11 16:45:54 (the 102 and 104 stock configs might not have any of those issues.. but I'm only tangentally involved on the bitstream/embeddedsw side of things) May 11 16:45:55 is the "E" for European so I wont have to sign it ; ) May 11 16:58:32 sgw1: you found the build? May 11 17:00:47 RP: yes I found it and trying to attach to the qmp socket now. I might need to install some qmp bits from qemu for the qmp-shell to work correctly. May 11 17:21:18 Hmm, enabling pam for mel bumped our main image size by 730KiB. not too bad for a non-tiny setup.. May 11 17:36:22 sgw1: they should be there in the sysroot? May 11 17:39:08 RP: yes, just needed to deal with getting the path right also. Seems that qemu is hung hard, qmp does not connect or respond May 11 17:43:59 sgw1: that is good data to have, we've always wondered... May 11 17:47:40 We can try on other failures or hangs. May 11 19:32:06 kergoth: 730Kib is not insignificant though, There are images where we are biting for every KB May 11 20:49:51 Hmm, anyone else seeing m4-native do_configure hang with "%n in writable segment detected" May 11 20:58:02 Hey. Does anyone know how to fix menuconfig in devshell. Where it does not present correctly.. May 11 20:58:10 https://pasteboard.co/K1rfBsu.png May 11 21:04:21 JPEW: the warning is fine but hang is not, and I dont know if hang is due to it or not, which distro is on host ? May 11 21:07:05 Ubuntu 18.04 May 11 21:09:24 @frosteyes: Is this only when you use a devshell or also when you run make menuconfig? May 11 21:10:28 @frosteyes: you might want to export TERM=something e.g. TERM=screen May 11 21:10:28 RobertBerger: only in devshell.. May 11 21:10:40 Is looking into it :) May 11 21:12:52 TERM=screen is a good thing May 11 21:12:59 now it looks correct - just to small May 11 21:13:23 @frosteyes: if you are on an xterm you can enlarge it May 11 21:14:16 @frosteyes: you can also try the OE_TERMINAL variable May 11 21:15:24 can you Thanks May 11 21:15:33 *Thanks for OE_TERMINAL May 11 21:15:35 @frosteyes: in my case it opens xterm - which is small and with CTRL+right mouse click -> Huge it's bigger May 11 21:16:01 hope it helps ;) May 11 21:17:04 https://docs.yoctoproject.org/singleindex.html#term-OE_TERMINAL May 11 21:19:28 RobertBerger: - OE_TERMINAL does not work. But TERM does... May 11 21:20:17 @frosteyes: check the values https://docs.yoctoproject.org/singleindex.html#term-OE_TERMINAL and define it e.g. in local.conf May 11 21:22:48 OE_TERMINAL is set to screen, but TERM is set from "inheritFromOS" to xterm So guess I need to look into why it inherit it. Notice it is inside a docker.. May 11 21:24:48 Thanks for the help RobertBerger May 11 21:25:29 @frosteyes: Hmm in a container it's even more fun ;) May 11 21:25:43 @frosteyes, since it's headless ;) May 11 21:25:50 Yes :) May 11 21:26:00 docker exec -it yocto bash to the rescue :) May 11 21:26:15 ls May 11 21:27:35 @frosteyes: I use build containers as well, but some tools actually need X and my container and my PC are different machines: this is my solution: https://github.com/RobertBerger/manifests/blob/master/resy-poky-container.sh May 11 21:27:56 search for USE_GUI where it is yes May 11 21:28:37 https://github.com/RobertBerger/manifests/blob/master/resy-poky-container.sh#L84 May 11 21:29:17 Thanks May 11 21:30:28 @frosteyes: enjoy May 11 21:38:08 Guess the easy solution is docker exec -it -e TERM=screen yocto bash May 11 21:38:34 this starts the bash in the docker with correct TERM value May 11 21:38:58 RP: did we come up with a policy on anything we can do with the fetcher to make "main" be a fallback default to master. Or was the end decision to just add explicit branch statements everywhere ? May 11 22:21:50 zeddii: I'm open to patch proposals or we just set the branch on urls May 11 22:23:27 zeddii: being explicit is perhaps the better option that magic in the fetcher May 11 22:26:56 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2145 was related to your meson changes I think May 11 22:29:34 RP: right, I'll do separate AB pass after fixing the SDK stuff May 11 22:31:09 kanavin: is https://autobuilder.yoctoproject.org/typhoon/#/builders/119/builds/271 and issue with the gdk changes? May 11 22:31:36 kanavin: I just started another build but perhaps I should abort now :/ May 11 22:32:14 RP: yes May 11 22:33:21 * RP retries with those dropped May 11 23:33:46 RP: ack'd. I'll just go with a branch, using the default was probably never a great idea. either that or nobranch and SRCREV. May 12 01:23:23 Is there a PACKAGE_EXCLUDE override? I.e. PACKAGE_INCLUDE? Some third-party recipes I'd like to avoid touching exclude some packages, but I'd like to include them for debug builds **** ENDING LOGGING AT Wed May 12 02:59:56 2021