**** BEGIN LOGGING AT Tue Apr 06 02:59:57 2021 Apr 06 04:29:29 has hob been discontinued? it is not available in my build environment Apr 06 07:31:59 yo dudX Apr 06 07:39:33 good morning Apr 06 07:55:55 hi . in my yocot/embedded project my rootfs mounts to ram, I want to know how to mount rootfs in another location like nand flash ? Apr 06 07:56:52 Hello there Apr 06 07:57:34 I am trying to upgrade the gpsd to 3.20 in my setup Apr 06 07:58:02 I am getting and error while bitbake gpsd. Apr 06 07:58:30 cc1: warning: command line option '-fvisibility-inlines-hidden' is valid for C++/ObjC++ but not for C Apr 06 07:59:00 Looks like I need to remove that option from BUILD_CFLAGS Apr 06 07:59:37 How do I do that? Apr 06 07:59:46 What is the best option. Apr 06 08:00:00 the bigger question is, how did it made into your cflags. maybe the gpsd build system is wonky and fetches flags from CXXFLAGS Apr 06 08:03:11 I can see /tmp/work/aarch64-fsl-linux/gpsd/3.20-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -fstack-protector-strong -O2 -pthread Apr 06 08:05:26 From the warning, the selected language  is C Apr 06 08:07:05 I tried passing -std=c++11 to CXXFLAGS Apr 06 08:07:21 Without much luck. Apr 06 08:07:37 Wondering what I am missing here.. Apr 06 08:08:54 Looks like I need to add something like CFLAGS:=$(filter-out -fvisibility-inlines-hidden,$(CFLAGS)) Apr 06 08:09:06 But how do I add this in a bb file? Apr 06 08:09:57 Any help? Apr 06 08:11:52 how about understanding the root cause first? isn't gpsd a c project? how can -fvisibility-inlines-hidden land in the cflags there? Apr 06 08:16:22   13 # ifdef __cplusplus Apr 06 08:16:22   14 extern "C" { Apr 06 08:16:23   15 # endif Apr 06 08:16:23   16 Apr 06 08:16:24   17 #include Apr 06 08:16:24   18 #include Apr 06 08:16:32 it is a c project Apr 06 08:17:54 https://download-mirror.savannah.gnu.org/releases/gpsd/ Apr 06 08:40:32 recipe-sysroot-native/usr/share/aclocal/visibility.m4:20:dnl Set the variable CFLAG_VISIBILITY. Apr 06 08:40:33 recipe-sysroot-native/usr/share/aclocal/visibility.m4:26: CFLAG_VISIBILITY= Apr 06 08:40:33 recipe-sysroot-native/usr/share/aclocal/visibility.m4:69: CFLAG_VISIBILITY="-fvisibility=hidden" Apr 06 08:40:33 recipe-sysroot-native/usr/share/aclocal/visibility.m4:73: AC_SUBST([CFLAG_VISIBILITY]) Apr 06 08:41:11 Looks like this option is coming from recipe-sysroot. Apr 06 08:43:38 dnf-native/4.2.2-r0/recipe-sysroot-native/usr/share/gettext/intl/Makefile.in:107:CFLAGS = @CFLAGS@ @CFLAG_VISIBILITY@ Apr 06 08:44:10 Looks bit convoluted. Apr 06 08:44:41 Earlier version of gpsd (3.12)  build correctly. Apr 06 08:45:13 After updating to new version this issue started popping out. Apr 06 08:45:53 devtool modify + git bisect to the rescue :) Apr 06 09:02:38 Hi everyone, need suggestions on linux integrity: Apr 06 09:02:53 1. Apr 06 09:02:53 I am using an i.MX8M Mini based platform to implement secure boot. Apr 06 09:02:54 The chain of trust implemented so far is as follows: Apr 06 09:02:54 bootrom => SPl => ATF => U-Boot => Kernel Apr 06 09:03:12 2. Apr 06 09:03:12 I want to extend the secureboot/chain of trust towards rootfs. Apr 06 09:03:13 I am using yocto and meta-security/meta-integrity layer to implement this. Apr 06 09:03:13 I have enabled all the configs related to IMA and EVM inside kernel Apr 06 09:03:29 3. Apr 06 09:03:30 when I try to test rootfs integrity using evmctl, it gives me an error: Apr 06 09:03:30 evmctl verify /usr/sbin/alsactl Apr 06 09:03:31 getxattr failed: /usr/sbin/alsactl Apr 06 09:03:31 errno: Operation not supported (95) Apr 06 09:04:34 any suggestions are appreciated on how to go about this problem. Thanks Apr 06 09:09:14 suniel: well, your filesystem has no support for xattrs, i guess Apr 06 09:09:20 what fs is it? Apr 06 09:10:24 and did you enable all kernel features for ima/evm? Apr 06 09:14:00 ext4 Apr 06 09:14:28 yes i have enabled all features for ima/evm Apr 06 09:15:01 did you enable CONFIG_EXT4_FS_SECURITY? Apr 06 09:16:18 no its not enabled Apr 06 09:16:51 see :) Apr 06 09:16:59 iam enabling it and running my tests Apr 06 09:18:32 these are my kernel configs for ima/evm Apr 06 09:18:34 CONFIG_INTEGRITY=y Apr 06 09:18:34 CONFIG_IMA=y Apr 06 09:18:35 CONFIG_IMA_WRITE_POLICY=y Apr 06 09:18:35 CONFIG_IMA_READ_POLICY=y Apr 06 09:18:36 CONFIG_IMA_MEASURE_PCR_IDX=10 Apr 06 09:18:36 CONFIG_IMA_AUDIT=y Apr 06 09:18:37 CONFIG_IMA_LSM_RULES=y Apr 06 09:18:37 CONFIG_IMA_SIG_TEMPLATE=y Apr 06 09:18:38 CONFIG_IMA_NG_TEMPLATE=y Apr 06 09:18:38 CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" Apr 06 09:18:39 CONFIG_IMA_DEFAULT_HASH_SHA256=y Apr 06 09:18:39 CONFIG_IMA_DEFAULT_HASH="sha256" Apr 06 09:18:40 CONFIG_IMA_APPRAISE=y Apr 06 09:18:40 CONFIG_IMA_LOAD_X509=y Apr 06 09:18:41 CONFIG_IMA_APPRAISE_BOOTPARAM=y Apr 06 09:18:41 CONFIG_IMA_TRUSTED_KEYRING=y Apr 06 09:18:42 CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y Apr 06 09:18:42 CONFIG_IMA_BLACKLIST_KEYRING=y Apr 06 09:18:43 CONFIG_IMA_X509_PATH="/etc/keys/x509_ima.der" Apr 06 09:18:49 suniel: use a pastebin please Apr 06 09:19:18 sorry qschulz, I will use a pastebin Apr 06 09:27:30 suniel: off topic ? Apr 06 09:28:30 mckoan: didnt get you. is my question out of topic Apr 06 09:29:44 suniel: https://community.nxp.com/ Apr 06 09:45:47 i wouldn't be too strict about it, but its still probably something that there is little support on out in the open. Apr 06 10:41:06 Trying out my luck once again, after the long Easter week-end has ended :) Apr 06 10:41:17 First of all, hello everyone :) Apr 06 10:41:25 I'm trying to understand why http://sstate.yoctoproject.org/3.1.6/ mirror is only matched for 2% of sstate-cache on Ubuntu 16.04/20.04 for core-image-minimal for qemuarm64? only poky 3.1.6 is cloned, no dirty git Apr 06 10:43:14 suniel: i agree with mckoan this is offtopic here. but as i said, you need to enable CONFIG_EXT4_FS_SECURITY. Apr 06 10:43:39 derRichard, agreed Apr 06 11:05:35 hi, on zeus, if i should rebuild with a different machine type, what is the procedure ? Should i "clean" or remove build/tmp ? Apr 06 11:14:12 ad__: no, just build Apr 06 11:14:25 ad__: what's your worry/concern? Apr 06 11:15:16 qschulz, thanks, so i should have something wrong in my machine files, since no new deply/images/dir is created Apr 06 11:15:32 build completes for the older machine Apr 06 12:54:45 ad__: did you cahanged it in local.conf ? Apr 06 12:55:22 ad__: did you change it in local.conf ? Apr 06 13:44:10 has hob been discontinued? it is not available in my build environment Apr 06 13:49:49 yates: yes, replaced by toaster Apr 06 14:04:53 RP: Do you know if the OMP_NUM_THREADS change help the AB memory usage? Apr 06 14:09:02 JPEW: maybe, hard to say so far Apr 06 14:27:14 zeddii: there were definitely some issues with :: in FILESPATH long time ago e.g. mentioned in https://git.openembedded.org/openembedded-core/commit/?id=b7279f99639774674da806d37d252f388f33055f so I would be careful with those FILESEXTRAPATH values Apr 06 14:27:52 hello guys ! Apr 06 14:28:04 to change the hostname of my image, I've added Apr 06 14:28:15 hostname_pn-base-files = "myhostname" Apr 06 14:28:21 to my configuration file Apr 06 14:29:14 but since I am also building a ramdisk image i would like to have a different hostname for this image Apr 06 14:29:22 different from the previous one Apr 06 14:29:29 how can I do that ? Apr 06 14:29:48 use a image post-rootfs hook to rewrite the hostname file Apr 06 14:30:37 or maybe a second .conf that imports the first, but overwrites the hostname? Apr 06 14:31:40 the point is that the ramdisk image is embedded in the fitimage of the "standard" image Apr 06 14:31:54 so basically it's built while building the core-image Apr 06 14:32:27 I tried to add the same line of code wuth the modified value in the image recipe Apr 06 14:32:41 zeddii: I'd echo the :: thing Apr 06 14:32:47 JaMa: I knew I remembered something about ::, thanks for the pointer! Apr 06 14:32:47 but I was unluky Apr 06 14:33:11 yah. I don't have any :: in meta-virt (at least not in my glance), but the counter example to what I was saying was a double :: :D Apr 06 14:33:56 zeddii: append with : on the end sounds wrong though Apr 06 14:34:07 it should be at the start Apr 06 14:34:40 maybe. but I don't think it sounds any more wrong either way Apr 06 14:35:00 either something needs to enforce it, or it is all just 'hope everyone does it the same way' Apr 06 14:35:15 rburton, something like do_rootfs_append() ? Apr 06 14:35:29 zeddii: we should do a pass over the layers and standardise. The current situation is asking for trouble Apr 06 14:36:13 yah. I'd wager that whatever is in most layers, depends largely on what example someone found when starting a recipe :D Apr 06 14:36:15 thekappe: no. google will take you to ROOTFS_POSTPROCESS_COMMAND Apr 06 14:36:20 hi mckoan ! sorry, seen your reply now. Well, i was erroneously typing a wrong char in machine type :) all works now. Apr 06 14:36:28 but zeddii is right that the default value ends with :, so appending with leading ':' looks correct, but that's what will introduce this :: :/ Apr 06 14:36:31 # set? /OE/build/oe-core/openembedded-core/meta/conf/bitbake.conf:344 Apr 06 14:36:34 # "__default:" Apr 06 14:36:38 Spooster: that will never work Apr 06 14:37:26 rburton, thanks Apr 06 14:40:25 insane.bbclass also says this: Apr 06 14:40:28 msg += " FILESEXTRAPATHS_append := \":${THISDIR}/Your_Files_Path\" or\n" Apr 06 14:40:28 msg += " FILESEXTRAPATHS_prepend := \"${THISDIR}/Your_Files_Path:\"\n" Apr 06 14:40:35 paulg: let me know if my replies about those patches make sense or I'm totally offbase with my reasoning somehow Apr 06 14:41:11 RP, yeah - I'm trying to digest that and catch up on other non-related stuff. Apr 06 14:42:24 The mirror tarball naming thing makes me think that we simply don't do full repo tarball mirroring unless explicitly asked for, or something to that effect. Apr 06 14:43:06 +1 post-rootfs hook for sure Apr 06 14:43:21 the revlist-in-the-tarball-name is unweildy and really don't want to go down that road. Apr 06 14:46:44 the only way that could work - with a large number of branches, would be to use similar to the pack naming scheme; the SHA1 over all the refs/objects. Apr 06 14:49:04 I do get your point about removing (some of) the control options from the SRC_URI and hiding them in the fetcher as "magic"; I just wouldn't have ever jumped right to doing that from square one. Apr 06 14:50:32 And I'm not sure how one would split a big history project in some other way hidden in the fetcher.... :-/ Apr 06 14:52:36 paulg: the mirror tarballing already does have a config option on whether we generate them Apr 06 14:53:16 yeah, I know - I'm just thinking that if that isn't on, then we allow --single-branch in some way. Apr 06 14:53:46 paulg: I get nervous about having conditional code paths but yes, there might be some potential there Apr 06 14:53:46 we'll really need to be able to do selective branches for some of these bloated repos ; that need isn't going away. Apr 06 14:54:21 paulg: right, agreed Apr 06 14:54:24 The Linux kernel (git) repo is getting to the side where it's overwelming various servers.. :( Apr 06 14:54:49 fray: upstream or ours? Apr 06 14:54:56 yeah, the 3G wgets aren't a sustainable option. Apr 06 14:55:07 cloned kernel.org Apr 06 14:55:12 they are getting large :/ Apr 06 14:56:41 I'm trying to understand why http://sstate.yoctoproject.org/3.1.6/ mirror is only matched for 2% of sstate-cache on Ubuntu 16.04/20.04 for core-image-minimal for qemuarm64? only poky 3.1.6 is cloned, no dirty git Apr 06 14:56:57 (sorry for spamming, my curiosity is killing me right now) Apr 06 14:57:17 16.06 no uninative support? (just guessing) Apr 06 14:59:02 qschulz: hashqeuiv broke our shared sstate :( Apr 06 15:00:59 RP: not sure to follow exactly? Apr 06 15:01:31 qschulz: we run builds on the autobuilder which mark artefacts as equivalent but there is no export of that data to your build Apr 06 15:01:34 RP, independent of what I'm trying to do with my shenanigans, we really should pursue the low hanging fruit of independently repacking that linux-yocto tarball Apr 06 15:01:46 therefore the autobuilder does something different to what your build does :( Apr 06 15:01:54 I'm not sure who owns what gets mirrored on yoctoproject.org Apr 06 15:02:12 paulg: basically you need to talk to halstead and I Apr 06 15:02:36 paulg: the stuff i generated by the autobuilder, halstead maintains the infrastructure Apr 06 15:03:17 RP: ah gotcha, so, expected :) probably would work with zeus I guess then? Apr 06 15:03:45 qschulz: yes. Ideally we want to export the equiv data somehow but we haven't quite worked that out yet :/ Apr 06 15:03:53 Don't need the latest just for training :) Thanks for the info RP, much appreciated Apr 06 15:04:03 *basic training* Apr 06 15:05:03 RP, ok - I guess I'll put in an email what I think we can do "for free" and send it to you and halstead Apr 06 15:07:24 hopefully that causes you less heartburn than my patch series. ;-) Apr 06 15:10:21 paulg: I do agree we need to do something with the alternates and the fetcher. We just need to get it right. 10 years on and I still have nightmares about fetcher v1 Apr 06 15:14:00 FWIW, I didn't really want to be touching the fetcher at all. Apr 06 15:14:42 but the giant downloads has become an issue that we can't turn a blind eye to any longer. Apr 06 15:14:55 it scares away users. Apr 06 15:15:39 paulg: I'd prefer not to touch it or maintain it ;-) Apr 06 15:15:45 mainly new users. Old farts like us have our own workarounds of course. Apr 06 15:16:27 paulg: I get it and I'm not trying to put you off with the review :/ Apr 06 15:17:04 heh, don't worry. It takes more than that to scare me off. :-P Apr 06 15:17:40 prepare the moat and boiling oil! Keep the heathens at the gate! Apr 06 15:21:30 configuring it is a pain, but the git shallow mirror tarball support is nice for this sort of thing, it explicitly is just what the recipe wants, no history except what history is requested, no branches beyond what's requested, and it's all in the filename. tradeoffs, though. Apr 06 15:22:15 I wonder if use of git bundles would be worthwhile eventually, you can bundle an entire repo or a subset, and git can interact with a local bundle like a remote, no need to unpack to ls-remote its refs Apr 06 15:22:49 course i don't think you can query a remote bundle, though, which isn't ideal, so still don't know if a remote bundle is newer than the one you've got.. Apr 06 15:31:34 RP I have someone complaining that libraries from a certain recipe are getting a date of 1969-12-31 17:00:00 hours (no idea which timezone) Apr 06 15:31:52 Any idea why this might be happening? I'm assuming reproducible builds might be changing timestamps? Apr 06 15:32:31 sounds like they are somehow using the eSDK, but I'm not sure Apr 06 15:38:29 Looking that appears to be a time of '0' in the timezone where the builder is Apr 06 15:39:58 fray: reproducibile builds did default to 0 in older code Apr 06 15:40:27 kergoth: its the remote listing piece which makes this so hard :/ Apr 06 15:42:19 unless the repo is specified as static/unchanging. :) Apr 06 15:44:52 This is gatesgarth Apr 06 15:44:58 Any idea when the default changed? Apr 06 15:47:26 fray: master, not sure what was backported Apr 06 15:48:37 zeddii: the FILESEXTRAPATHS in bitbake.conf looks really suspect :( Apr 06 15:51:26 * zeddii nods Apr 06 15:53:55 zeddii: hah, look at the code in meta/classes/utils.bbclass: # Remove default flag which was used for checking Apr 06 15:53:55 extrapaths = extrapaths.replace("__default:", "") Apr 06 15:54:21 " # The ":" ensures we have an 'empty' override" Apr 06 15:55:59 that is horrible Apr 06 15:59:15 eeee! Apr 06 16:02:30 derRichard: after enabling CONFIG_EXT4_FS_SECURITY, xattrs can be accessed Apr 06 16:03:01 derRichard: thanks for the help Apr 06 16:04:41 :-) Apr 06 16:04:59 derRichard: If i query using: evmctl ima_verify /usr/sbin/alsactl it outputs "xattr ima has no signature" Apr 06 16:05:09 how should i understand this Apr 06 16:05:50 *is* /usr/sbin/alsactl signed? Apr 06 16:07:01 RP: I had one perf-tests patch that fixes builds on 5.12-rc5+, I don't see it on master-next. Not sure if you want that in the upcoming release to future proof when people eventually do try and use 5.12+ against the release. Apr 06 16:07:21 I'm ok either way. just thought I'd mention it. Apr 06 16:11:56 derRichard: in my /sys/kernel/security/ima/ascii-runtime-measurements file, it is signed with ima-ng and has a sha256 Apr 06 16:17:50 zeddii: ever tried to get TF-A debug output, eg. on 3399 ? Apr 06 16:19:34 RP: i can't help but wonder if our mirrors sh ouldn't just have mirrors of the git repositories directly instead of tarballs.. Apr 06 16:28:37 kergoth: A single clone with worktrees would be really efficient Apr 06 16:29:07 bare clone probably? I don't remember if you can do a worktree checkout from a bare clone Apr 06 16:33:43 JPEW: you can't directly do one, but there are some ways it can be done ;) witness all the linux-yocto machinery in the past :D Apr 06 16:33:58 that being said, I haven't checked a recent git to see if they added such a beast in. Apr 06 16:46:30 zeddii: nm, found out about the serial baudrate issue Apr 06 16:47:01 I'll have a couple of patches for optee support, when that's fully working Apr 06 16:48:37 kergoth: the challenge is people wanting to mirror things with only wget working through a proxy Apr 06 16:48:50 kergoth: maybe we should give up on that as not our problem though Apr 06 16:50:31 JPEW, zeddii: that can always been done cheaply with a "git clone --shared" Apr 06 16:51:04 oh yes. we know the mechanics, in gory detail Apr 06 16:51:11 there are many gremlins in all of the options Apr 06 16:51:28 try relative alternates, try 3 deep alternates, etc, etc, we've hit them all. Apr 06 16:52:21 ok :D Apr 06 17:29:32 /join #gcc Apr 06 18:38:35 Hi guys Apr 06 18:39:13 I'm compiling a python module with py-setuptools in the rdepends list Apr 06 18:39:39 And setuptools3 is inherited Apr 06 18:40:36 Still I have no module named setuptools error :/ Apr 06 18:40:48 Any guess? Apr 06 18:52:25 linums: the setuptools3 inherit is only for native builds. Do you have "python3-setuptools" added to the RDEPENDS? Apr 06 18:53:04 I do have Apr 06 18:53:20 But it's failing during the native package Apr 06 18:58:54 khem: around? Apr 06 19:17:43 khem: nvm, libyui patches comming soon Apr 06 19:33:50 with part --align 1024 in my first WIC partition, does the partition start at 0 or 1024? Apr 06 19:35:06 vdl: 1024 I think. I'd use --offset instead if you can Apr 06 19:35:55 JPEW: hum I looked for this but it isn't mentioned in https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-kickstart Apr 06 19:36:44 JPEW: also silly question, how do I know if I'm using MBR or GPT for my SD card? (I don't want to overlay the 512 first bytes of the MBR) Apr 06 19:37:32 overlap* Apr 06 20:01:34 vdl: Hmm. There are a few OE-isms in the kickstart code (--align is one) Apr 06 20:01:54 vdl: Oh sorry Apr 06 20:02:01 I see what you are saying Apr 06 20:02:47 vdl: --offset isn't there because that's the old manual: https://docs.yoctoproject.org/ref-manual/kickstart.html Apr 06 20:04:26 JPEW: docs/latest is an old manual? :-D Apr 06 20:12:27 JPEW: I see an occurence of --offset in the older https://docs.yoctoproject.org/gatesgarth/ref-manual/ref-kickstart.html though. It is what you meant? Apr 06 20:18:13 vdl: yes Apr 06 20:19:21 so the option was removed I supposed. Apr 06 20:19:38 vdl: No, it was added Apr 06 20:20:08 I think it only got added to the sphinx version of the docs Apr 06 20:20:50 i've enabled buildhistory via 'INHERIT += "buildhistory"' in my /conf/local.conf, but after bitbaking i find no /buildhistory directory. is that still the default location? Apr 06 20:22:13 JPEW: isn't it weird to have --offset option in byte and --fixed-size in Mbytes? How would you define a 512 partition? Apr 06 20:25:58 TOPDIR is , right? Apr 06 20:26:44 INHERIT += "buildhistory" Apr 06 20:26:44 BUILDHISTORY_COMMIT = "0" Apr 06 20:26:44 BUILDHISTORY_DIR = "${TOPDIR}/buildhistory" Apr 06 20:27:06 vdl: Ya, some of the default suffixes are inconsistent Apr 06 20:27:27 512-byte* Apr 06 20:27:28 But, they can't really be changed easily because of leagacy file. IIRC you can specify a suffix to make them what you want Apr 06 20:30:57 vdl: Here's the suffixes supported: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/ksparser.py#n54 Apr 06 20:32:35 vdl: --offset defaults to Kilobytes Apr 06 20:32:54 JPEW: ho --offset is in K then, thanks. btw how do I know if I'm using MBR or GPT for my SD card? Apr 06 20:38:31 vdl: `bootloader --ptable=gpt` or `bootloader --ptable=msdos` Apr 06 20:43:31 JPEW: perfect. Ho I see mdos is the default, thank you. Apr 06 21:10:09 i'm getting a configure error for libgcc and i need to troubleshoot it. the log does not contain the actual ./configure command. is there a way i can capture that? Apr 06 21:10:26 within "DEBUG: Executing shell function do_configure" Apr 06 21:15:39 I would expect a log somewhere in `build/tmp/work` but does the build failure not tell you where the log is? Apr 06 21:16:37 Spooster: i have the log, but it does not show the commands issued, just the stdout/stderr messages resulting from the commands Apr 06 21:17:12 at least that's what it looks like to me. here it is: http://paste.ubuntu.com/p/hB3dSRZ7qx/ Apr 06 21:18:20 I think configure can be simplified to: "running the configure.sh" script... which was given a heap of arguments Apr 06 21:18:47 agreed, and i want to see those arguments Apr 06 21:18:52 of which, there are quite a number of unrecognized arguments... Apr 06 21:19:00 some are on line 18 in your log Apr 06 21:19:13 i want to see the actual command Apr 06 21:20:14 yates: read the run. script next to the log file Apr 06 21:20:17 it has the commands run Apr 06 21:20:28 kergoth: +1 Apr 06 21:20:32 you could also do a do_configure_prepend () { set -x; } or so and re-run and chekc the log Apr 06 21:20:39 in the recipe in question of course Apr 06 21:21:11 see also the EXTRA_OECONF variable, the autotools_do_configure task defiend in oe-core/meta/classes/autotools.bbclass, and CONFIGUREOPTS if defined Apr 06 21:22:01 k, thanks much kergoth Apr 06 21:22:04 i will Apr 06 21:23:07 yates: iirc bitbake -v will set -x too, and it looks like setting BB_VERBOSE_LOGS = "1" in your recipe will set -x for all its tasks already Apr 06 21:23:12 https://github.com/openembedded/bitbake/blob/master/lib/bb/build.py#L419 Apr 06 21:43:34 @JaMa: Thank you for the version-info yesterday! Apr 06 22:00:27 Hi. My buildprozess craps out as soon as add the hello-mod example module. Here is the pastebin: https://pastebin.com/mR6eDgM3 Apr 06 22:00:57 When i add the same module to the quickbuild example, using the same recipe everything works fine. Apr 06 22:01:41 I 'append' the module by specifying: MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-hello" Apr 06 22:02:19 If anyone has an idea, or a tip where i should look, please write it down here - my irc seems to disconnect regularly, so I will look at the logs. Apr 06 22:06:39 Can I change the python version for a yocto branch easily? Apr 06 22:53:54 * RP starts a 3.3 rc1 build Apr 06 23:23:49 * armpit crosses fingers Apr 06 23:38:56 JaMa: thanks for libyui patches, I do not have tests for building from clean downloads/ folder Apr 06 23:39:25 perhaps there could be such a build added Apr 06 23:40:00 armpit: sounds good, I am not sure if we have some patches which are dependent. on master things yeet Apr 06 23:56:52 khem: you're welcome Apr 06 23:57:52 JaMa: the pidgin-sipe was an oversight will you be aable to quickly test out my suggestion Apr 06 23:59:07 khem: your suggesting doesn't work, I've already sent different fix Apr 06 23:59:34 https://lists.openembedded.org/g/openembedded-devel/message/90593 Apr 07 00:04:52 JaMa: hmm ok thanks for fixing it **** ENDING LOGGING AT Wed Apr 07 02:59:57 2021