**** BEGIN LOGGING AT Fri Feb 19 02:59:57 2021 Feb 19 03:02:36 om26er, I build dunfell meta-security Feb 19 03:02:40 https://gitlab.com/akuster/meta-security/-/pipelines/255835402 Feb 19 03:03:49 my alt build set : DISTRO_FEATURES_append = " apparmor pam smack systemd" Feb 19 03:05:22 I build those on qemuarm64 & qemux86-64. Feb 19 03:06:44 om26er, thanks for the info Feb 19 07:52:52 ok morning Feb 19 07:54:36 yo dudX Feb 19 09:18:06 Trying to transition from libMali to Mesa I'm getting hit but those old opengl/gles ambiguities - what's the status of this ? rburton, have anything evolved since https://www.yoctoproject.org/pipermail/yocto/2012-September/009239.html ? Feb 19 09:27:53 hello guys Feb 19 09:28:11 I'm building an image using wic Feb 19 09:28:32 I noticed that the wic image also add entries in /etc/fstab Feb 19 09:29:00 what I can do if I don0t want some partitions automatically added in /etc/fstab ? Feb 19 09:29:35 (apart from manually editing /etc/fstab after booting) Feb 19 09:38:27 rburton: with libMali I had succeeded (with a few .bbappend snippets) in having a libgl-free system. mesa OTOH does not look like it will accept to provide gles and not libgl (at least with current packaging) - digging into this Feb 19 09:51:42 Hello, on dunfell poky from a9206a27e4bab7cd6658f, I have this unclear error: "ERROR: Task (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_install) failed with exit code '134'" What's happen? Feb 19 09:56:00 vygu2: 132-128=6, looks like SIGABRT - you surely have something more in your logs Feb 19 10:00:04 @yann what log? Feb 19 10:01:16 log.do_install for linux-libc-headers (but usually tmp/log/cooker/shadow-ghost/console-latest.log will show something) Feb 19 10:01:41 the message you show is the final report, it points to something hapenning earlier Feb 19 10:05:58 in tmp/log/cooker/ald-atom/console-latest.log I see exactly the same error without more context Feb 19 10:06:04 NOTE: Running task 939 of 6978 (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_prepare_recipe_sysroot) Feb 19 10:06:05 NOTE: recipe linux-libc-headers-5.4-r0: task do_prepare_recipe_sysroot: Started Feb 19 10:06:05 NOTE: recipe linux-libc-headers-5.4-r0: task do_prepare_recipe_sysroot: Succeeded Feb 19 10:06:06 NOTE: Running noexec task 940 of 6978 (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_configure) Feb 19 10:06:06 NOTE: Running noexec task 941 of 6978 (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_compile) Feb 19 10:06:07 NOTE: Running task 942 of 6978 (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_install) Feb 19 10:06:07 ERROR: Task (/home/yoctouser/poky/../poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb:do_install) failed with exit code '134' Feb 19 10:08:30 log.do_install, then Feb 19 10:10:13 you should use a paste service rather than pasting multiline logs directly here, btw Feb 19 10:14:35 I have not got log.do_install in /tmp/work/core2-32-sbr-linux/linux-libc-headers/5.4-r0/temp Feb 19 10:23:37 there would be an abort() in do_install before it starts logging anything ? you could try running bitbake under "strace -f" to make sure who gets this signal Feb 19 10:50:17 qschulz: gland someone reads my patches :) Feb 19 10:50:23 er, glad :) Feb 19 10:51:20 yann: i heard that current mesa won't build libgles without libgl, which is sad as that used to work fine Feb 19 10:52:38 vygu2: the log you want is /tmp/work/core2-32-sbr-linux/linux-libc-headers/5.4-r0/pseudo/pseudo.log Feb 19 10:52:48 rburton: I confirm this :| Feb 19 10:54:10 RP: i had the short thought that this is pseudo related, but shouldn't it show the new error notice then? Feb 19 10:54:17 I've switched to an intermediate goal: disable GLX. Most bb's out there make the assumption that opengl+x11 => glx Feb 19 10:54:31 yeah Feb 19 10:54:38 the opengl distro feature was intentionally vague Feb 19 10:54:44 to avoid turning into a billion features Feb 19 10:58:23 LetoThe2nd: I think its aborting so early its not visible Feb 19 10:58:55 RP: ah ok. so next time i see somebody with an abort we should alwasy ask for pseudo.log? Feb 19 10:59:23 LetoThe2nd: yes, it might help to update the wiki page about this too Feb 19 10:59:35 good morning Feb 19 11:00:35 @RP https://pastebin.com/raw/SJgDFmEE Feb 19 11:00:40 can someone remind me what is the bitbake command to figure out where a package comes from i.e where is the recipe that puts it in the rootfs please? Feb 19 11:01:04 intera91: oe-pkgdata-util somethign Feb 19 11:01:38 vygu2: in dunfell? Feb 19 11:02:22 vygu2: that is really odd since PSEUDO_IGNORE_PATHS = "/usr/,/etc/,/lib,/dev/, [...] from http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf?h=dunfell#n690 Feb 19 11:02:29 i.e. /dev/ is there Feb 19 11:02:35 RP: :) the first few patches are hard to review though, happy that Peter had a look at them because I definitely missed the typo he found Feb 19 11:03:18 qschulz: I missed it too, I'd spent a long time trying to get them into shape though Feb 19 11:03:34 vygu2: there is no message in that log about the abort which is odd too Feb 19 11:04:22 qschulz: that typo is fixed in master-next Feb 19 11:06:16 RP: oh no surprise it took time to get them into shape, and they definitely don't look like fun patches to make. Easy for typos to slip in Feb 19 11:08:16 RP: sad that we have to keep some kind of backward compatibility for users that relied on some "side-effects" of INCOMPATIBLE_LICENSE Feb 19 11:08:25 (and I might be such user.. lemme check :p) Feb 19 11:08:40 qschulz: the trouble is it wasn't a sideeffect, it was the behaviour :/ Feb 19 11:08:57 RP: gtk+3 and xserver-xorg both want /me screams Feb 19 11:09:10 @yann "strace -f bitbake linux-libc-headers" give a lot of logs, what special I have to look for or do you need? Feb 19 11:09:34 vygu2: look for SIGABRT Feb 19 11:09:38 yann: yeah welcome to a world of pain Feb 19 11:09:43 vygu2: grep them for "Abort" Feb 19 11:09:53 yann: honestly easiest to just build glx but never actually install it Feb 19 11:10:00 RP: I wanted to say "undocumented" behavior Feb 19 11:10:22 qschulz: it really was recommended/supported sadly Feb 19 11:10:47 RP: but yeah, I guess it's a case of "ABI compatibility" "nightmare" the Linux kernel has to deal with too Feb 19 11:11:04 qschulz: we have our share of this Feb 19 11:11:10 and the consequences of what I'm suggesting are probably too big to just ignore them Feb 19 11:11:44 though, technically.... you could really throw a bb.fatal if INCOMPATIBLE_LICENSE does not have an SPDX licnese couldn't you? Feb 19 11:11:46 qschulz: sadly, I think so. After my discovery of *GPLv3 in testing I may have to make this code worse again Feb 19 11:12:01 qschulz: technically, we could Feb 19 11:12:32 rburton: nothing a couple of PACKAGECONFIG_remove can take care of, for now Feb 19 11:12:57 RP: wondering now how this bb.fatal thingy would work with user-provided licenses (e.g. qt's) Feb 19 11:13:23 the question would rather be, what do we want to do about the situation, and how do we move forward Feb 19 11:13:35 qschulz: right, we're into a world of corner cases. We could fatal error on anything in the SPDX map Feb 19 11:13:52 qschulz: I decided it was better to make it approximately work Feb 19 11:13:59 yann: patches welcome for sure where things have changed Feb 19 11:15:28 RP: I'm always wary with "approximately work" for license stuff... :/ especially since the multilib story a few months ago. Don't have anything better to suggest right now though, so I feel you Feb 19 11:15:42 hello. yesterday I asked about patch contribution to openembedded. I checked master branch if the problem my patch is adressing is present in master and it's not (webkitgtk version was updated since dunfell) Feb 19 11:16:25 qschulz: I know, I'm wary too Feb 19 11:16:30 now, should I post my patch against dunfell exclusively and if yes, how do I emphasize this in the patch submition? Feb 19 11:17:41 rburton: we need a plan first. I would suggest aiming for removal of the "opengl" feature/packageconfig, with sole use of egl/glx and libgl/gles2/gles3. But there we need to fit the swrast on/off switch somewhere Feb 19 11:18:16 you're suggesting replacing opengl with six+ alternatives? Feb 19 11:19:06 some of them are already there :) Feb 19 11:22:45 many packages use "opengl" as meaning "libgl" while many others use it as "glx if x11" ; several packages already have gles1/gles2 (also "glesv2" even) Feb 19 11:28:44 @RP grep "Abort" give nothing, @yann https://pastebin.com/raw/6XUcmsR5 Feb 19 11:29:35 vygu2: the key bit will be around killed by SIGABRT (core dumped) Feb 19 11:29:38 [pid 163772] +++ killed by SIGABRT (core dumped) +++ Feb 19 11:38:24 @yann @RP yes I know it is a SIGAPRT, but why from this commit? what is my config error in my yocto to obtain this? Feb 19 11:38:58 my team will soon submit a patch where the sigbrt erro prints the pseudo.log. We are tired of having pseudo aborts in machines which are not reachable :) Feb 19 11:44:32 vygu2: https://wiki.yoctoproject.org/wiki/Pseudo_Abort Feb 19 11:45:10 ptsneves: in pseudo itself or in bitbake? Feb 19 11:46:05 RP in bitbake. The bbfatal just says there was a pseudo abrt and where to get the pseudo.log but often the pseudo.log is in a workspace of a machine that not every dev has access to Feb 19 11:46:31 zbodek: first, check if gatesgarth has the same issue. If so, send to it first and then to dunfell. Just say that it does not apply to master because the version was bumped. I think you'll probably be asked to provide the upstream patch that fixed it and not one you did Feb 19 11:46:47 zbodek: but first and foremost, what is this patch fixing? Feb 19 11:47:21 and given the difficulty  of reproducing the issues...It is very annoying. The last patch of Tomasz Dziendzielski was not enough for us it seems :) He is working on the full pseudo printout on the error message. Any special requests on the topic? Feb 19 11:52:26 ok I know why my compilation fails, it needs glibc 2.32 and the warrior branch is using 2.29 Feb 19 11:53:02 is it safe to backport the gllibc recipe director in recipes-core? Feb 19 11:53:13 directory* Feb 19 11:53:21 intera91: go ahead and try, but probably not. Feb 19 12:03:28 qschulz: webkitgtk's code loads "libWPEBackend-fdo-1.0.so" which does not exist because unversioned .so files are not included into -dev package. I can see that the newer version of webkitgtk doesn't have that issue. Feb 19 12:04:42 qschulz: The patch I wanted to post is forcing keeping of the unversioned .so file for wpebackend-fdo_1.4.1.bb package Feb 19 12:06:06 qschulz: The solution could be either this or updating webkitgtk version. Though I don't know which is preferred Feb 19 12:08:14 zbodek: no updates allowed. Find how they fixed this unversioned so file in newer version of webkitgtk. (might be a fix in Yocto too, can't rule this out) Feb 19 12:08:28 it's probably libWPEBackend-fdo.so.1.0 I guess now Feb 19 12:15:26 qschulz: I know they changed webkitgtk code for sure (there is no reference to unversioned .so file in the) but how do you suggest to fix it without bumping up package version or changing recipe to keep .so file? Patch an older webkitgtk to do what newer webkitgtk does with that lib? Feb 19 12:26:12 zbodek: is this gatesgarth or dunfell? I'd suggest talking to the maintainer for that series Feb 19 12:28:47 RP: I use dunfell and that is where I encountered this issue. So you suggest I should e-mail maintainer of this first? Feb 19 12:32:29 @RP I do not understand, with my meta I have not this error with gatesgarth. I build my yocto with CROPS. Feb 19 12:33:19 CROPS ubuntu18.04 Feb 19 12:34:44 I have maybe a error in my distro config, my machine config, or my image, but with this error I don't find where Feb 19 12:36:30 zbodek: sakoman is ultimately the person who needs to review and accept the patch Feb 19 12:37:07 vygu2: dunfell updated to include these pseudo fixes. Its as it you have part of but not all the pseudo changes Feb 19 12:37:36 vygu2: I don't understand why the abort isn't in your log for example, or why it would warn about a path which is in the ignore list Feb 19 12:37:46 vygu2: something doesn't add up Feb 19 12:38:07 RP: thanks, I will contact him Feb 19 12:47:18 vygu2: did you start from a clean TMPDIR after updating to this version? Feb 19 12:49:02 Hello, Feb 19 12:49:03 I have a question about the PACKAGECONFIG and how to interact with it. Feb 19 12:49:07 There is a recipe with : Feb 19 12:49:07 PACKAGECONFIG[egl] = "--enable-egl,--disable-egl,virtual/egl" Feb 19 12:49:07 How can I interact with this recipe to disable egl (cleanly) ? Feb 19 12:49:08 I'm going to retry with a clean tmpdir and without sstate-cache to be sur Feb 19 12:50:20 vygu2: I doubt sstate-cache would cause it FWIW Feb 19 12:51:13 yannholo: make sure that PACKAGECONFIG_pn-yourrecipe does not contain "egl". Feb 19 13:00:17 LetoThe2nd if the recipe has a PACKAGECONFIG ??= "packageA packageB egl packageC" do I put PACKAGECONFIG_pn-therecipe="" or PACKAGECONFIG_pn-therecipe="packageA packageB packageC" Feb 19 13:00:19 @RP exactly the same error Feb 19 13:00:29 with a clean tmp Feb 19 13:00:37 yannholo: a bbappend for said recipe to remove egl from PACKAGECONFIG Feb 19 13:01:20 yannholo: i personally would put PACKAGECONFIG_pn-therecipe="packageA packageB packageC" into the distro file, but it depends a bit. Feb 19 13:02:05 vygu2: and there is no abort message in linux-libc-header's pseudo.log? Feb 19 13:02:25 vygu2: what does bitbake -e | grep PSEUDO_IGNORE_PATHS show? Is /dev in that variable? Feb 19 13:04:01 qschulz: LetoThe2nd: I guess the bbappend is the way to go, I think I expected the PACKAGECONFIG[xx] to work differently... Thx Feb 19 13:07:06 or from any configuration file Feb 19 13:08:42 yannholo: why do you want to disable egl BTW? does it not compile for some reason? (I'm thinking of a missing check on DISTRO_FEATURES opengl) Feb 19 13:08:56 or gles can't remember, the graphic stuff is a bit confusing to me still Feb 19 13:10:04 @RP in pseudo.log there are only notification about path mismatch. no /dev in https://pastebin.com/raw/Gcp4SDUK Feb 19 13:11:11 vygu2: ok, there is something wrong with the setting of PSEUDO_IGNORE_PATHS Feb 19 13:11:20 vygu2: is the variable history there? Feb 19 13:13:59 @RP all logs https://pastebin.com/raw/pB1wWWPw Feb 19 13:17:53 vygu2: can you get more context around "$PSEUDO_IGNORE_PATHS [3 operations]" Feb 19 13:19:42 @RP what do you means? it is the raw bitbake -e output. Feb 19 13:20:48 do you ask bitbake -e or bitbake -e TARGET? Feb 19 13:21:34 vygu2: I'm saying you've filtered that output to only the lines containing PSEUDO_IGNORE_PATHS and I'd like to see the lines surrounding the above line I mentioned Feb 19 13:22:12 there should be some history about the variable there and what the 3 operations were Feb 19 13:23:30 @RP OK but I filtered nothing. How do I enable the full trace? Feb 19 13:24:10 vygu2: that pastebin is not all the output, you used grep, right? so try grep -C 10 or something Feb 19 13:29:20 @RP OK sorry, I did not understand. https://pastebin.com/raw/4SF9ZXds Feb 19 13:30:36 vygu2: can you check whether your bitbake.conf sets PSEUDO_IGNORE_PATHS ? Feb 19 13:30:44 vygu2: there is no mention of it doing so in that log Feb 19 13:32:27 nothing about PSEUDO_IGNORE_PATHS in my bitbake.conf Feb 19 13:32:48 vygu2: yet dunfell has http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf?h=dunfell#n690 Feb 19 13:33:00 vygu2: so why does your bitbake.conf not look like that one? Feb 19 13:35:18 RP: when/how do we apply SOURCE_DATE_EPOCH when building the packages ? Feb 19 13:35:40 dl9pf: see reproducible*.bbclass Feb 19 13:36:11 dl9pf: basically the environment Feb 19 13:36:35 hmm Feb 19 13:37:40 my lead is atm: looking at repro[A|B]/initscriptsrpm difference in mtimes are for files we copy during do_install Feb 19 13:39:27 dl9pf: those also tend to get changed in fixup_perm() in package.bbclass Feb 19 13:39:49 ok looking Feb 19 13:40:25 dl9pf: well, I'm going off your previous comment about it being directories and so on from the common install -d Feb 19 13:40:52 dl9pf: The situation may have changed, I haven't seen a newer diff Feb 19 13:41:57 let me send an update ... Feb 19 13:42:49 diffoscope-initsccripts-rpm-mtimes https://usercontent.irccloud-cdn.com/file/qydo3idO/grafik.png Feb 19 13:43:28 initscript-recipe-do-install https://usercontent.irccloud-cdn.com/file/alnNHTZM/grafik.png Feb 19 13:44:09 so the question is how the SDE would apply to these as we install them at bitbake exec time Feb 19 13:44:13 dl9pf: this is dunfell? Feb 19 13:44:18 no, master-next Feb 19 13:44:33 I'm now all on master next for this. rpm + core-image-minimal Feb 19 13:45:01 dl9pf: these are the files in the rpm? Feb 19 13:45:19 dl9pf: have you compared to the timestamps in WORKDIR/packages-split ? Feb 19 13:45:27 i see no diff in the files themselves, just in the mtimes ... sec let me check Feb 19 13:46:09 dl9pf: I'm working on the assumption that this works in ipk/deb so something is happening in package_rpm Feb 19 13:47:01 yep, packages-split is different mtimes Feb 19 13:47:16 e.g. the etc/init.d Feb 19 13:47:33 dl9pf: which distro? Feb 19 13:48:03 buildmachine ? debian 10 buster Feb 19 13:48:10 dl9pf: DISTRO :) Feb 19 13:48:25 whatever oe-selftest sets Feb 19 13:48:26 qschulz: After some more tests I think you are right Feb 19 13:48:27 Some errors are resolved by removing the distro feature opengl Feb 19 13:48:27 I still have issues with this recipe http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/cairo/cairo_1.16.0.bb?h=zeus Feb 19 13:48:28 It is a depencency of http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.16.2.bb?h=zeus Feb 19 13:48:28 And it try to build the package gles2, wich gives me the error "imx-gpu-viv PROVIDES virtual/libgles2 but was skipped: missing required distro feature 'wayland'" Feb 19 13:48:29 I am not sure that I need caire nor libgles2 for my apps to work... Feb 19 13:48:43 dl9pf: I'm wondering if you miss INHERIT += "reproducible_build" from poky.conf Feb 19 13:51:15 does the oe-selftest not enforce that ? Feb 19 13:51:24 yannholo: how did you remove the distro feature, in which file? Feb 19 13:52:14 2021-02-19 12:59:27,165 - oe-selftest - DEBUG - Writing to: poky-build-repro/main-st-33497/conf/selftest.inc Feb 19 13:52:15 INHERIT += "reproducible_build" Feb 19 13:52:18 dl9pf: you're right, it seems to Feb 19 13:52:54 dl9pf: seeing mtimes vary like that is usually a sign that source date epoch isn't working :/ Feb 19 13:53:11 yannholo: check the bbappends for those recipes too, I know NXP likes to add bbappends for many many many recipes Feb 19 13:53:24 so you might just be in a corner case they don't test Feb 19 13:53:44 my suspicion is that 'install' and update-rc.d in our do_install / do_install_append do not apply SDE Feb 19 13:54:05 other bits do, or we'd see way more packages Feb 19 13:54:16 dl9pf: but then how would deb/ipk work Feb 19 13:54:44 idk atm. just looking at rpm side of things Feb 19 13:55:41 dl9pf: I just had a look at my initscripts build and for some reason it thinks SDE is 0 for that build Feb 19 13:55:44 i see especially things lig glibc-gconf* glibc-charmap glibc-binary-localedata ... I assume we do the splitting for these moving things around while packages-split Feb 19 13:56:01 dl9pf: what happens is that the files timestamps are clamped at that when the package is created Feb 19 13:56:17 yes, that is what should happen 'tm' Feb 19 13:56:19 dl9pf: so I'd guess rpm needs the same clamping behvaiour Feb 19 13:56:56 qschulz For now I added  DISTRO_FEATURES_remove += " opengl" in my local.conf Feb 19 13:56:58 question is if we fulfill the 'if' aka clamping macro 1 *and* SDE env var valid Feb 19 13:57:15 dl9pf: http://git.yoctoproject.org/cgit.cgi/opkg-utils/commit/?id=c3cc95693048bdd57a82069bad47abbc72a1932e for example Feb 19 13:57:33 dl9pf: I wonder if rpm doesn't like SDE=0 ? Feb 19 13:58:48 dl9pf: an experiment might be to set SDE != 0 for initscripts? Feb 19 13:59:08 dl9pf: I had this "argument" with xorg-minimal-fonts recently: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9113bc1170b5c25d0eee8f1784c9e212eb81c9aa Feb 19 14:01:21 dl9pf: We could change the default of 0 in reproducible_build to something more recent (make it configureable too?) Feb 19 14:01:50 I did add reproducible_build_simple in my run as well Feb 19 14:02:25 RP, dl9pf Ya, it should be non-zero if you have reproducible_build_simple Feb 19 14:02:51 e.g. initscripts ... that are files from ${WORKDIR} so they have all been copied by us just before Feb 19 14:02:52 dl9pf, JPEW: I think build_reproducible will override simple though Feb 19 14:03:06 hello I read the documentation but where do you find the meta-altera repo ? it is not in Source-repositories ? Feb 19 14:03:13 dl9pf: the code which examines the dates will probably skip WORKDIR though Feb 19 14:03:18 that sounds like confusing for users Feb 19 14:03:21 should be additive Feb 19 14:03:47 shouldn't we touch our files copied to WORKDIR with SDE ? Feb 19 14:03:59 the doc is brief-yoctoprojectqs/index.html Feb 19 14:04:22 dl9pf: we'd have to change a ton of other files too, this is why we clamp instead Feb 19 14:04:23 yannholo: ok, was worried you added it to the recipe only. Check the freescale/nxp layers to find out if they haven't forgotten to put a conditionnal on opengl distro feature in one of their bbappends Feb 19 14:04:58 hmm ... ok let me check that rpm does the right thing wrt clamp or if the condition to enable it fails ... Feb 19 14:05:31 dl9pf: I'm still guessing a non-zero value is worth a try Feb 19 14:05:57 @RP That seems to be it. I don’t know why my colleagues from 3 years ago found it good to play with the content of bitbake.conf with sed and copy it locally. I will investigate. Thank you so much for your help Feb 19 14:06:48 ok, let me try that in parallel Feb 19 14:08:12 vygu2: np, glad you know roughly what is wrong :) Feb 19 14:18:00 Question: What is 'sato' (specifically). More exactly, if I were to swap out X11 for a wayland compositor, would that still be "sato" ? Feb 19 14:22:07 JPEW: sato is meant to be a reference/test/demo of the graphics stack in YP/OE showing that the stack works and how to do a simple kiosk style UI that does basic app execution Feb 19 14:22:41 so I'd say yes, swapping out X11 for wayland would still be what its meant to be with more modern tech Feb 19 14:22:47 all roughly speaking Feb 19 14:22:49 rburton: ^^^ Feb 19 14:32:59 qschulz : Maybe PACKAGECONFIG_append_imxgpu3d = " egl glesv2" in a cairo_%.bbappend from freescale it what is causing the issue ? Feb 19 14:35:13 yannholo: absolutely Feb 19 14:35:27 yannholo: why don't you just remove imxgpu3d from your MACHINEOVERRIDES? Feb 19 14:35:35 or, not add it in the first place? Feb 19 14:35:40 since it seems you don't want gpu support? Feb 19 14:37:00 qschulz: I guess this is the next thing I am going to find out how to do ! Feb 19 14:38:15 qschulz: (I may need h264/vp8 hardware encoding at some point, but maybe it is not linked ?) Feb 19 14:40:30 hello guys ! Feb 19 14:41:00 I need to add the binary firmware file of a module to /lib/firmware Feb 19 14:41:20 so I've added the following entries in my kernel.bbappend recipe Feb 19 14:41:37  do_install_append_(){ Feb 19 14:41:47 install -d ${D}/lib/firmware Feb 19 14:42:06  cp ${WORKDIR}/fw.bin ${D}/lib/firmware Feb 19 14:42:07 } Feb 19 14:42:29 by the way the rootfs doesn't have neither the file nor the directory Feb 19 14:42:38 any suggestion ? Feb 19 14:45:46 yannholo: that's the VPU :) Hantro drivers is what you want IIRC?? Not entirely sure. Feb 19 14:47:07 JPEW: considering the matchbox desktop/panel (that make up sato) are essentially libraries with five line main() functions, i've been wondering how much effort it would be to make a weston shell that pulls those in for the UI Feb 19 14:47:44 combined with the existing policy for full screen windows the end result will look similar but be gtk3/wayland instead Feb 19 14:47:55 thekappe: oe-pkgdata-util find-path /lib/firmware/fw.bin Feb 19 14:48:57 thekappe: -firmware-fw will be the package I'm guessing from https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n650 Feb 19 14:49:16 qschulz, thanks. Feb 19 14:49:35 rburton: Possibly. I was looking at https://puri.sm/projects/phosh/ Feb 19 14:49:58 rburton: I built it on my desktop, and it's pretty slick Feb 19 14:50:31 does it scale reasonably? Feb 19 14:50:36 qschulz: That's a good news ! A simple PACKAGECONFIG_remove_imxgpu3d = " egl glesv2" seams to do the trick for now. I'm gonna try to validate like that before I remove the whole imgpu3d. Feb 19 14:50:51 @qsculz, but it's not clear to me how to procedd Feb 19 14:50:52 JPEW: a layer to test it out would be interesting for sure Feb 19 14:50:57 Phoc that! Feb 19 14:51:05 * zeddii chuckles Feb 19 14:51:09 rburton: Seems to. It's designed to run on a phone and looks fine on my desktop Feb 19 14:51:18 thekappe: have you run the command I sent you? Feb 19 14:51:26 what's its output Feb 19 14:51:39 I'm waiting a build to finish Feb 19 14:54:07 once you found the package which has your firmware, you just need to add that package to your image Feb 19 14:54:26 Unable to find pkgdata directory Feb 19 14:54:30 whoa Feb 19 14:54:45 mmm wait Feb 19 14:54:59 do_install_append_ is this a typo or do you REALLY have a trailing underscore? Feb 19 14:55:22 typo, sorry. Feb 19 14:55:49 I am using do_install_append_MYMACHINENAME(){} Feb 19 14:56:53 I found this folder using "find . -name fw.bin" Feb 19 14:57:43 a Feb 19 14:57:55 "/very/long/path/packages-split/kernel-firmware-fw" Feb 19 15:01:19 rburton: What's in their main() ? Feb 19 15:10:38 yup, add kernel-firmware-fw to your image recipe then Feb 19 15:13:22 qschulz, just inspected the .wic/lib/firmware. it's there. thanks dude Feb 19 15:13:34 JPEW: http://git.yoctoproject.org/cgit/cgit.cgi/matchbox-desktop-2/tree/src/main.c#n67 Feb 19 15:15:33 rburton: Hmm, I'm not sure Feb 19 15:15:54 Wayland compositors don't really follow the "server/desktop" split like X does Feb 19 15:41:37 * armpit way ??? Feb 19 16:09:08 RP: SDE should not be 0 for rpm Feb 19 16:09:42 it will fall through in if ( sde && clamp_macro = 1 ) Feb 19 16:17:20 Hello everyone. Does anyone use kas? I see that it generates a "build" folder, but is there a way to set the name of the build folder? I would like to have two kas.yml files with different configurations and different build folder. Is it the correct way ? Feb 19 16:28:28 flash27: You can definitely have multiple kas.yml and call "kas build yourfile.yml" Feb 19 16:29:03 flash27: For the build directories it seams that there is no easy way : https://github.com/siemens/kas/issues/40 Feb 19 16:34:12 dl9pf: right, that is what I suspected. Feb 19 16:42:19 just a small question: I have backported a few thyings in the warrior branch like boost and glibc ... now I want to save my work to our private gitlab account, in short I need to delete the build/tmp directpry but what else is safe to delete in poky/ ??? things like the cache I suppose ... Feb 19 16:42:51 after that relocate the git ... Feb 19 16:48:18 intera91: just commit your changes and push to your repo. Anything that isn't git controlled, is not required. Feb 19 16:48:23 alimon: did you see the emails about the ptest repo? Feb 19 16:48:52 zeddii: thank you Feb 19 16:49:54 Hello, what would be a propper way to override the FULL_OPTIMIZATION flag in bitbake.conf ? Feb 19 16:51:57 just set it in your local.conf, or in the recipe if its a recipe-specific problem Feb 19 16:53:26 rburton oh ! okai Feb 19 17:13:12 dang, another pseudo abort today: path mismatch [1 link]: ino 65012298 db '/tmp/go-link-452191931/a.out' req '/tmp/go-link-389679905/000000.o'. Feb 19 17:13:18 i feel like maybe it would be safe to exclude /tmp? Feb 19 17:13:30 either that or my recipe is broken and shouldn't be faffing about in /tmp? Feb 19 17:16:49 RP: yes i push a patch to fix the tests Feb 19 17:17:57 RP: is there about the larga output and exitcode? Feb 19 17:18:31 alimon: there is email saying that the head revision is broken, did you force push? Feb 19 17:20:47 alimon: there was a commit, "Fix inappropriate ioctl when detacting tty" that was on master and disappeared with that last push Feb 19 17:21:06 alimon: revision 834670317bd3f6e427e1ac461c07ada6b8936dfd Feb 19 17:21:24 how are defined kernel modules recipes, e.g. kernel-module-ipv6? Feb 19 17:21:57 I mean, are all kernel modules implicitly or explicitly defined somewhere? Feb 19 17:22:44 RP: yes my mistake sorry for the trouble Feb 19 17:23:02 RP: i pushed the original rev Feb 19 17:23:25 alimon: thanks :) Fixing the other issue too does sound good! Feb 19 17:23:55 alimon: we just reference that revision in the current recipes so we need to try and keep it! :) Feb 19 17:25:18 glad its fixed Feb 19 17:26:06 RP: yep i know, i was doing some rebases and then made the mistake of force push... Feb 19 17:26:23 question about the populate_sdk. I have the problem that some headers are not in the sdk I populated (e.g. system/graphics.h, ion/ion.h, ..). Am I right in the assumption what I just have to include the line BBCLASSEXTEND = "nativesdk" in the respective bitbake recipe? Feb 19 17:26:36 and if yes, how do I know what header file belongs to which recipe? Feb 19 17:28:46 alimon: all too easy, I've done it before... Feb 19 17:33:04 created a new layer with bitbake-layers and added it, it contains a recipe but bitbake won't acknowledged it (what did I forget?) Feb 19 17:33:46 hello guys Feb 19 17:35:24 is it possible to bind an ethernet node of the device tree to a specific eth name ? eg: I want that the DT node ethx@addrx is named eth0 and ethy@addry eth1 Feb 19 17:35:37 I've seen /etc/systemd/network/99-default.link Feb 19 17:36:14 but here the match is done upon some values that don't involve the DT node Feb 19 17:40:29 RP: With the "glued-together" repos, it can be confusing to send patches upstream. Feb 19 17:40:31 Would it make more sense to suggest prefixing the patches with [PATCH layer name] (as appended to BBFILE_COLLECTIONS), e.g. "[PATCH yocto] poky: fix X", or "[PATCH core] add Y"; Feb 19 17:40:33 or maybe with [PATCH $LAYERDIR], e.g. "[PATCH meta-poky] poky: fix X", or "[PATCH meta] add Y"? Feb 19 17:41:38 vdl, for the modules, there a pattern like that in PACKAGES_DYNAMIC in kernel.bbclass, but I haven't tried to search further. kernel-module-split.bbclass sounds revelant too Feb 19 17:42:25 my best guess is that they are created dynamically depending on your conf (menuconfig, ...), but just a guess Feb 19 17:42:34 kyanres_: like is there for example a kernel-module-veth (related to CONFIG_VETH=m)? Feb 19 17:43:33 vdl: there's a bbclass that looks at what modules were built and packages them individually by that naming pattern. There's also a meta package 'kernel-modules' that pulls them all in. Feb 19 17:44:21 intera91, in that-layer/conf/layer.conf there is a pattern used to match the recipes. is your file matched by this pattern ? Feb 19 17:44:26 vdl: a number of those names don't make sense unfortunately :( Feb 19 17:45:14 zeddii: ok so this is independent from the kernel config framework, you need to have CONFIG_FOO=m enabled by any means in order to have kernel-module-foo dynamically packaged, correct? Feb 19 17:45:22 correct. Feb 19 17:45:36 kyanres_: yes , thanks problem sorted there has to be a recipes-/ dirtectory in which to place the .bb Feb 19 17:45:38 RP: you mean in my examples or the actual layer names? Feb 19 17:46:37 vdl: I mean the names used in the real world by several layers Feb 19 17:46:45 clear Feb 19 17:47:55 RP: I agree that the difference between $LAYERDIR and what's appended to BBFILE_COLLECTIONS is even more confusing :) e.g. meta-poky -> "yocto"; openembedded-core/meta -> "core" meta-yocto-bsp -> "yoctobsp" and so on. Feb 19 17:49:26 RP: a 3rd suggestion is the optionally prefix the patch with "PATCH project dir", e.g. "[PATCH poky]", "[PATCH openembedded-core]" or "[PATCH meta-yocto]", but I'm not sure it'd be clearer for you (and the contributors) Feb 19 17:50:51 Anyone experienced catkin_make errors with ROS Yocto Layer? I have created a custom image for iMX8MM target device, roscore and stuff are working however when I try to do catkin_make for a simple publisher example I get an error of "roscpp not found", although it is available in the installed ROS packages. Feb 19 17:52:32 zeddii: so is kernel-module-foo the only generic way to make sure that a recipe depends (or recommends) a specific kernel config? Feb 19 17:52:44 yep. Feb 19 17:53:35 zeddii: last question, does kernel-module-foo handles only CONFIG_FOO=m or does it satisfy CONFIG_FOO=y as well? Feb 19 17:53:37 or you can do something custom and search around in the shared-workdir kernel .config and error if what you are looking for doesn't exist. But that's a custom thing to do, it can't be expanded generically. Feb 19 17:53:42 vdl: nope. Feb 19 17:53:43 RP: Did you see my bitbake patch to fix multiconfigs with "-" in them? Feb 19 17:54:03 a built in .config won't generate anything, so you have to dig around. Feb 19 17:55:06 which is why I created the KERNEL_FEATURES error for linux-yocto references. It will error if a feature fragment can't be applied. so covers both the built in and module variants. but you have to obviously enable them from a kernel .bbappend. Feb 19 17:55:50 zeddii: hm ok. So I understand that you can do whatever you want, but the "yocto way" would suggest to go with kernel modules rather than built-in config, so that you have a generic way to specify dependencies and recommendations, am I correct? Feb 19 17:56:54 I wouldn't say modules versus built-ins for the depends is any more correct or yocto-correct than anything else. That distinction is more about size, boot method, flexibility, etc. Feb 19 17:57:34 tightly bound packages to a kernel config either need to root around a bit, or trigger off a distro feature that both the kernel and recipe can respect, or some other variant. Feb 19 17:58:10 zeddii: a concrete example is systemd-container depending on kernel CONFIG_BRIDGE and CONFIG_VETH in order to have virtual ethernet link between containers. Feb 19 17:58:27 because in a given kernel, another config can easily y select your option, the package goes away and the build reaks. Feb 19 17:59:36 JPEW: I have now, I'm just going to trust you got that right if the tests still pass ;-) Feb 19 17:59:45 * RP has enough of a headache with the licensing Feb 19 18:00:16 that's no more complex than what we do in meta-virtualization for all the other container runtimes. You'll either need to check the .config or have a distro feature to coordinate the bits, check it at image creation time (in a custom rootfs command), etc. Feb 19 18:05:17 JPEW: did you see the parsing force shutdown patch. That looks a lot like the issues we've seen Feb 19 18:05:30 JaMa: ^^^ you may want to look at that bitbake patch for the issues we talked about Feb 19 18:13:28 RP: open to a REPRODUCIBLE_FALLBACK_SDE ??= ... instead of the '0' ? Feb 19 18:14:25 SOURCE_DATE_EPOCH_FALLBACK maybe ? Feb 19 18:14:41 ok Feb 19 18:14:45 dl9pf: but yes, the idea is what I was thinking Feb 19 18:15:14 testbuilds take forever, when done I'll send a patch Feb 19 18:16:21 and we might need to ensure that the values recovered for SDE from sstate are not 0 either. that might bite ppl or we do reset it if '0' Feb 19 18:17:38 got bitten by SDE from sstate being 0 Feb 19 18:37:09 zeddii: sorry I'm confused again, does IMAGE_INSTALL_append = " kernel-module-ipv6" enables CONFIG_IPV6=m for me or do I have to do it on my own? Feb 19 18:38:24 vdl: a change in one recipe won't affect another. that only changes what packages the image will try to install Feb 19 18:38:39 * JPEW looks Feb 19 18:40:34 RP: Ya, that seems reasonable Feb 19 18:41:11 kergoth: thank you Feb 19 19:42:10 zeddii: how do I force kernel .config to use CONFIG_CPU_BIG_ENDIAN=y Feb 19 19:42:11 for a qemu machine which is otherwise Big-endian by default Feb 19 19:42:49 ah I have a defconfig seed where I can change it Feb 19 20:19:48 khem: hey, can you pick this for dunfell https://patchwork.openembedded.org/series/25751/# ? Thanks Feb 19 22:04:09 I have more python3targetconfig patches for dunfell. Do they need to be sent for gatesgarth first? (I'm not using gatesgarth) Feb 19 22:07:44 nevermind I someone might have sent them already. Feb 19 22:09:10 RP: JPEW: rpm: same=8117 different=0 different_excluded=1 missing=0 total=8118 = core-image-sato on master-next Feb 19 22:12:59 dl9pf: \o/ Feb 19 22:21:26 dl9pf: sounds great! :) Feb 19 22:23:24 any EPOCH in mind for the FALLBACK ? ... 1 or pick a number Feb 19 22:25:18 dl9pf: $ date -d 2011-4-6 +%s Feb 19 22:25:18 1302044400 Feb 19 22:47:44 dl9pf: Same one in reproducible_build_simple.bbclass? Feb 19 22:53:04 JPEW: I'd be tempted to be different just so we can see which it is... Feb 19 23:00:17 +1 Feb 19 23:01:22 RP, dl9pf: Works for me :) Feb 19 23:02:01 What happened on 2011-4-6 ? Feb 19 23:15:41 JPEW: I shall leave that for people to figure out :) Feb 19 23:16:03 * RP can't resist an easter egg Feb 19 23:16:21 that was the plan ;) Feb 19 23:18:59 RP: I saw in the weekly status the mention that glibc 2.33 breaks builds in containers (https://wiki.yoctoproject.org/wiki/Weekly_Status). Can you give me a reference or some details to what exactly that is? I reckon we are chasing the same issue and I'm close to getting to the roots of it, Feb 19 23:19:31 alephan: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0ba0a534a3e32423a3a1a51aeb60f7bd9cbbd822 Feb 19 23:20:30 Right. This is no the same issue. There is a new issue actually where glibc 2.33 is breaking sysconf reporting on L1 cache linesize. Feb 19 23:21:05 not* Feb 19 23:21:38 alephan: hmm, we've not come across that one yet :/ Feb 19 23:21:48 I got into this by running qemu 4.2.0 with glibc 2.33 and because qemu in that version has an assert of it's value it brakes Feb 19 23:22:03 You didn't come across it because the newer version of qemu (5.2.0) defaults to 0 Feb 19 23:22:17 And it doesn't break the assertion anymore. Feb 19 23:22:53 alephan: is there a recommended fix? Feb 19 23:22:55 marex: reach out to Armin he maintains stable releases Feb 19 23:23:10 khem: did you see those hangs again btw? Feb 19 23:23:14 * alephan sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/xNkdoVcBxjWzqZsYoZBUAEBB/message.txt > Feb 19 23:23:53 I have a fix yes. khem I'm currently testing it with the qemu x86 buids Feb 19 23:24:27 alephan: please do share when its ready, sounds like something we should fix Feb 19 23:24:42 RP: lately I am seeing qemu hangs with musl/mips Feb 19 23:25:08 khem: but from that change we were discussing? I thought I'd tested that and the autobuilder seems ok Feb 19 23:25:10 RP: background I'm trying to fix dunfell with glibc 2.33 on the host Feb 19 23:25:22 Will do. Feb 19 23:25:36 alephan: right, we're definitely interested in that Feb 19 23:25:47 sakoman: ^^^ Feb 19 23:25:54 This is the last one in my pile Feb 19 23:26:05 (for my testing matrix of course) Feb 19 23:26:45 alephan: I think we got through the issues we had with 2.33 in core... Feb 19 23:26:49 I hope anyway :) Feb 19 23:27:10 Yes - some of those are backports for pseudo Feb 19 23:27:24 Which I got the patches before seeing yours Feb 19 23:27:39 (I only checked master branch in pseudo - don't ask) Feb 19 23:28:07 alephan: did you reach the same conclusions in pseudo out of interest? Feb 19 23:28:20 I still worry we're missing some wrappers Feb 19 23:28:24 Yes. Exactly the same Feb 19 23:28:29 With some indentation Feb 19 23:28:55 I think we are good Feb 19 23:29:09 alephan: did you find the interesting AT_EMPTY_FILE issue? Feb 19 23:29:17 er, PATH Feb 19 23:29:31 No, I got into the uid no key 1000 Feb 19 23:29:59 that one took me a while Feb 19 23:30:00 (under pseudo) Feb 19 23:30:30 Let's just say it was a busy last half of the week Feb 19 23:33:06 alephan: the AT_EMPTY_PATH is the cause of the no key XXX issues :/ Feb 19 23:33:55 And that was fixed by the wrappers, right? Feb 19 23:34:00 (afair) Feb 19 23:35:55 Actually I'm wrong https://git.yoctoproject.org/cgit/cgit.cgi/pseudo/commit/?h=oe-core&id=60e25a36558f1f07dcce1a044fe976b475bec42b Feb 19 23:36:24 right, that was the fix for that issue Feb 19 23:36:53 Funny enough I didn't backport that and it got me out of the python uid "key" issue Feb 19 23:37:12 That gets me thinking Feb 19 23:38:43 So I have a temporary fix now for glibc - just confirmed it with qemux86. I'll push. The annoyance though remains when using the host's glibc 2.33 Feb 19 23:39:36 But a qemu backport on the assert will "fix" that at least for compilation. Feb 19 23:54:58 RP: khem This is the revert https://lists.openembedded.org/g/openembedded-core/topic/patch_glibc_bring_back_l1/80769661?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80769661 Feb 19 23:57:34 khem: kuster ? Feb 19 23:59:06 marex: yes Feb 19 23:59:29 Andrei: can you build glibc with `--enable-tunables=no` instead and see if that helps Feb 20 00:00:43 Sure Feb 20 00:06:10 khem: all right Feb 20 00:12:42 alephan: I think we're going to have to bring that one up with glibc themselves, I'm nervous about reverting that Feb 20 00:14:43 I'll do that too. This will be a workaround for the meanwhile. I don't think it will cause problems. Feb 20 00:15:17 alephan: it is good to have it on the list, we can discuss it and people then know to be aware of it Feb 20 00:15:50 Yup. At the core we know that we are affected by it Feb 20 00:15:54 And we have a workaround Feb 20 00:16:24 alephan: exactly Feb 20 00:16:32 I think its just tunable issue, glibc 2.33 is now using cpu tunables Feb 20 00:16:49 and its not reporting it back since cpu detection is not right Feb 20 00:17:14 I'm building for that ^ Feb 20 00:26:27 khem: no dice Feb 20 00:33:13 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1832/steps/11/logs/stdio - breaking my builds! ;-) Feb 20 01:04:28 For those of you interested in the icache line size bug in glibc 2.33, here is the upstream report: https://sourceware.org/bugzilla/show_bug.cgi?id=27444 Feb 20 01:55:21 Andrei: try removing --enable-cet Feb 20 02:14:36 RP: blerg. I ran the tests... Feb 20 02:23:07 RP: Huh, it passes on master (with my patch), fails on master-next Feb 20 02:29:44 RP: Ah, sorry. The patch didn't get applied correctly because it does a rename and I sent it from poky. Sorry Feb 20 02:37:19 RP: Sent an updated patch with the prefix removed **** ENDING LOGGING AT Sat Feb 20 02:59:57 2021