**** BEGIN LOGGING AT Tue Feb 25 02:59:57 2020 Feb 25 05:50:47 do not run autoreconf Feb 25 05:51:02 perhaps override run_configure Feb 25 05:52:39 to something like do_configure () { oe_runconf } Feb 25 06:14:38 So I have another issue working with non-standard install prefixes... Feb 25 06:15:56 What I've done is create a paths.bbclass which my layer's recipes inherit, and this class (A) Ensures that do_populate_sysroot() does not miss the libraries installed into /opt/foo and /opt/bar... (B) Adds -L statements for /opt/foo and /opt/bar into LDFLAGS Feb 25 06:16:52 Also it extends EXTRA_OECMAKE with -DCMAKE_SYSTEM_LIBRARY_PATH, so that all the cmake find_library() calls find their dependencies in the correct /opt locations Feb 25 06:18:57 But here's the problem, when I use -L${STAGING_DIR_TARGET}/opt/foo in LDFLAGS, I manage to find the libraries when linking shared libraries, but I don't manage to find indirectly linked dependencies (libraries which require other libraries) when linking executables Feb 25 06:19:43 when linking the executables, I need LDFLAGS = "-L/opt/foo -L/opt/bar" instead and then that part works Feb 25 06:20:18 This resolves to the correct sysroot path because the g++ link statement is given --sysroot Feb 25 06:20:59 For some reason, I cannot solve both cases by specifying both full paths and sysroot relative paths in LDFLAGS (which would probably be very wrong anyway) Feb 25 06:22:06 But I've found that if I specify -L${STAGING_DIR_TARGET}/opt/foo, AND I add a custom ld.so.conf to ${STAGING_DIR_TARGET}/etc, THEN the indirect linking works when linking executables also Feb 25 06:22:27 But I'm not sure how to correctly create that ld.so.conf in the sysroot as a part of the build process Feb 25 06:22:50 Any ideas ? Or any pointers to "How do to multiple install prefixes correctly" ? Feb 25 06:23:01 s/do to/to do Feb 25 06:26:08 I am migrating my custom meta layers from jethro to sumo. I am getting the below error and I am not able to narrow down why it works on jethro but not on sumo Feb 25 06:27:40 kernel-source/scripts/gcc-version.sh: line 27: arm-poky-linux-gnueabi-gcc: command not found Feb 25 06:28:17 i commented out all the SRC_URI entries in linux-imx_%.bbappend file Feb 25 06:42:18 New news from stackoverflow: How to add ldd utility to bitbake image Feb 25 06:53:48 JPEW, are you and Douglas working together ? Just wondering if I should inform him about the patch you proposed regarding SOURCE_DATE_EPOCH Feb 25 06:59:52 JPEW, also I noticed that SOURCE_DATE_EPOCH is in BB_HASHBASE_WHITELIST, which explains why setting it didn't trigger rebuilds here all the time. which is kind of at odds at being able to set it explicitly methinks Feb 25 07:22:33 | /nobackup/sikumar3/inode_sumo/buildnew/tmp/work-shared/imx6uloib/kernel-source/scripts/gcc-version.sh: line 26: arm-poky-linux-gnueabi-gcc: command not found Feb 25 08:14:11 is the git repo for meta-freescale down or did it move in some way? Feb 25 08:18:33 sven^: https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ looks good to me. Feb 25 08:24:59 Anyone have experience in building python modules which uses setuptools3 in combination with a build extension using cmake? It seems like it's not trivial to get the cmake invokation from setuptools to use all the right config which cmake.bbclass usually fix for you. Feb 25 08:26:16 erbo: no experience, but my gut feeling is that you need manual append/prepend mangling. Feb 25 08:26:29 and deciding upon one class as the base. Feb 25 08:29:57 I'm considering just rewriting setup.py to not use cmake. I've been trying for a while now and wonder if it's actually worth it. I just used cmake since it was a convenient way to get a nice local workflow where I could use qtcreator while developing. Feb 25 08:30:39 I should have seen the Yocto integration problems coming though :) Feb 25 08:30:45 LetoThe2nd: git://git.yoctoproject.org/meta-freescale does not work Feb 25 08:31:00 I can't clone the repo Feb 25 08:31:34 sven^: i know that there have been hiccups with the repos, but thought they wree sorted out. Feb 25 08:31:58 sven^: I could clone it now Feb 25 08:32:29 ah, there have? It's the first time in 2 years it stopped working for me Feb 25 08:32:39 erbo: yeah, just retried and it works Feb 25 08:32:42 thanks Feb 25 08:59:26 i am getting below errors for "bitbake linux-imx" Feb 25 08:59:26 kernel-source/scripts/gcc-version.sh: line 26: arm-poky-linux-gnueabi-gcc: command not found Feb 25 08:59:41 can anyone help me to understand? Feb 25 09:02:00 siva: seriously, asking every hour is not going to do you any good. Feb 25 09:14:29 i apologize for keep asking the same questions often! Feb 25 09:17:10 siva: first: you should explain *exactly* whay you are doing Feb 25 09:17:42 siva: second: follow the official way http://freescale.github.io/#download (replace rocko with whatever you need) Feb 25 09:18:03 s/whay/what Feb 25 09:19:32 repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml Feb 25 09:19:53 added few meta layers in sources/base/conf/bblayers.conf Feb 25 09:20:50 added new custom.conf in my meta-custom-machine/machine/conf/custom.conf Feb 25 09:21:23 added new linux-imx_%.bbappend file in meta-custom-layer/recipes-kernel/linux/ Feb 25 09:21:31 bitbake core-image-base Feb 25 09:25:28 siva: repo init ? Feb 25 09:26:32 yes, we are using repo commands to clone the imx-linux-sumo Feb 25 09:28:31 siva: Can you build images using just the sources fetched from imx-manifest with none of your changes/additions? Feb 25 09:29:35 yes, if i remove my meta layers from base/conf/bblayers.conf and build, it works fine Feb 25 09:29:41 DISTRO=fsl-imx-xwayland MACHINE=imx6ulevk source fsl-setup-release.sh -b build-ul Feb 25 09:29:45 bitbake core-image-base Feb 25 09:30:02 but when i try the below, it doesn't work: Feb 25 09:30:16 DISTRO=fsl-imx-xwayland MACHINE=custom_machine source fsl-setup-release.sh -b build-ul Feb 25 09:30:21 bitbake core-image-base Feb 25 09:30:41 kernel-source/scripts/gcc-version.sh: line 26: arm-poky-linux-gnueabi-gcc: command not found Feb 25 09:34:49 siva: Are you using a custom kernel recipe? Feb 25 09:36:55 yes Feb 25 09:36:55 ../sources/meta-inode-oib/recipes-kernel/linux/linux-imx_%.bbappend Feb 25 09:45:10 siva: I recommend you go through the changes in your bbappend and any custom settings in your machine config carefully, try to isolate what causes the issue Feb 25 09:52:28 ok, i have included the imx6ulevk.conf in my machine file Feb 25 09:54:28 i am not sure whether i need to add COMPATIBLE_MACHINE some where? Feb 25 10:18:48 Hi all, I have to manage around 50 libraries. The question is, where is the better place to specify wich version to use ? ditro.conf ?, site.conf ? The purpuse is, of course, to have only one file to manage :D Feb 25 10:20:35 PinkSnake: as the library selection defines the ABI that any application can use, its a pretty clear case for DISTRO, in my opinion. Feb 25 10:21:28 LetoThe2nd Ok thank you for replying, there i sno trouble to include other files from distro.conf ? Feb 25 10:23:20 PinkSnake: look at poky.conf, poky-bleeding.conf, poky-tiny.conf and conclude for yourself. Feb 25 10:23:33 LetoThe2nd thx! Feb 25 11:40:44 Hi. If I want Yocto to not strip a specific binary. How should I do that? Adding `INHIBIT_PACKAGE_STRIP = "1"` to local.conf obviously affect all binaries Feb 25 11:43:20 New news from stackoverflow: mq_open() with O_CREAT fails while open() with O_CREAT was successful Feb 25 11:44:19 nacknick maybe create a bbappend of the .bb and add `INHIBIT_PACKAGE_STRIP = "1"` Feb 25 11:55:37 nacknick, alternativeley use a pn override in a global file like local.conf, like INHIBIT_PACKAGE_STRIP_pn- = "1" Feb 25 12:02:15 Hello everyone Feb 25 12:03:03 Is there a way for bitbake to not check the sstate mirrors if the same exist locally? Feb 25 12:04:20 logan87: can you rephrase? what is the actual usecase? Feb 25 12:04:23 A fresh build got a significant speed boost after the introduction of `SSTATE_MIRRORS` Feb 25 12:04:53 But running consecutive builds spends time on `Checking sstate mirror object availability:...` Feb 25 12:05:03 When the sstate is now available locally Feb 25 12:05:53 just remove the directive again, then? Feb 25 12:06:54 Fair :) Thought there was perhaps a innate way to set the priorities Feb 25 12:07:38 i.e Only go for sstate mirrors unless you can find everything you need locally Feb 25 12:08:47 locally = `build/sstate-cache` Feb 25 12:09:10 LetoThe2nd: Anyways, thanks Feb 25 12:09:50 logan87: i'm not saying that it does not exist, but i havent' heard of it. maybe ask the mailing list? and if its useful, send a patchset :) Feb 25 12:10:43 PinkSnake kroon - Thanks. and if I want Yocto to compile with `-marm` flag? Feb 25 12:11:31 Instead of `-mthumb` Feb 25 12:12:35 logan87: it should only hit the mirrors if it doesn't exist locally Feb 25 12:19:48 nacknick https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-TUNE_CCARGS ? Feb 25 12:21:40 RP: Thanks. You know when this was introduced? Am currently on warrior. Feb 25 12:26:28 logan87: it should always have done that Feb 25 12:29:56 @RP: Hmm... That doesn't seem to be my case. Is there a certain "trigger" for it? When I remove the `SSTATE_MIRRORS` it builds without the mirror loading quickly. Feb 25 12:30:19 As soon as it's there, the `Checking sstate mirror object availability:` kicks in Feb 25 12:30:50 logan87: are you on a very slow link? Feb 25 12:31:26 LetoThe2nd: 1-2MB/s Feb 25 12:34:25 logan87: are you saying you have everything locally needed yet its still checking the mirror? Feb 25 12:34:43 Now I am running the build in docker, and am passing the repo into the containter as a mounted drive Feb 25 12:35:05 So the build directory is persistent Feb 25 12:36:10 @RP: Anyways, don't want to drag you to deep into this. Thanks for sharing the expected behavior, will open a bug in case it isn't something specific to my setup Feb 25 13:18:17 RP: any idea if/when this patch might get into master (or if it needs further refinement)? https://patchwork.openembedded.org/patch/169954/ Feb 25 13:20:04 smurray: we do have the psplash issue still and I merged the patches thinking it wasn't showing up :( Feb 25 13:21:25 tgamblin: I guess its probably ok to go in... Feb 25 13:22:54 RP: if it's not the kind of tool that we want in oe-core, I can always put it back to being a function in my .bashrc :) Feb 25 13:25:47 tgamblin: I think I was torn between scripts and scripts/contrib Feb 25 13:26:02 tgamblin: we should probably encourage shared helpers to some degree Feb 25 13:26:18 tgamblin: I also worry about maintenance overhead/testing Feb 25 13:26:56 smurray: if you think you could fix it quickly, help would be appreciated Feb 25 13:27:09 RP: That's fair. I can change it to sit in scripts/contrib then? I'm also noticing a typo in the usage() part, so I should probably resend anyway Feb 25 13:27:36 tgamblin: the contrib directory has limited visibility so you're probably ok where it is Feb 25 13:28:06 tgamblin: sorry, I should try and be more decisive about some of these things! Feb 25 13:28:47 RP: No worries. Just figured after we started using variations of it internally fairly frequently that it'd be worth sharing Feb 25 13:28:59 I'll send a final update with the typo corrected Feb 25 13:29:03 tgamblin: that is good data to put in the commit message Feb 25 13:29:27 RP: That we're using it internally? Feb 25 13:29:29 people often forget "why" rather than "what" Feb 25 13:29:39 tgamblin: that you see multiple people implementing it badly Feb 25 13:30:19 RP: Ah Feb 25 13:35:33 what is this tool and i wonder if i have a copy of it too :) Feb 25 13:37:27 rburton: builds PN for all qemu machines in glibc and musl Feb 25 13:37:36 rburton: we wanted an easy way to tell bitbake to cycle through all of the qemu arches for both glibc and musl. Originally it was a one-liner that created blank files with .good and .bad extensions in the build folder, but then it became a bash function, and now a script Feb 25 13:37:45 ah i don't have that Feb 25 13:38:05 i do have a little thing that does a build, moves to a different point, does another build, and dumps buildhistory Feb 25 13:38:29 If only we paid attention to the autobuilder history generation Feb 25 13:39:31 I've been thinking about how it could eventually get it to the level of a menuconfig-style ncurses tool so you can select specific qemu machines and maybe real targets Feb 25 13:39:46 RP: the autobuilder showing the buidhistory for each master build would be nice Feb 25 13:39:59 tgamblin: eventually you end up with toaster! :) Feb 25 13:40:07 rburton: it does Feb 25 13:40:10 RP: reinventing the wheel since 2019 Feb 25 13:40:51 tgamblin: amateur, far too new to this :) Feb 25 13:40:54 RP: as in easily viewable in the autobuilder ui? Feb 25 13:41:26 rburton: https://autobuilder.yocto.io/pub/non-release/ right hand column ? Feb 25 13:42:45 RP: how can we get that in https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/746 or included in a mail Feb 25 13:43:48 rburton: adding to the buildstep isn't so hard, "mail" can be done, but to who? Feb 25 13:43:57 yocto-builds? Feb 25 13:44:33 rburton: who's going to read it? We have the performance stuff, nobody looks Feb 25 13:44:42 i look at the performance stuff! Feb 25 13:44:45 (sometimes) Feb 25 13:44:57 rburton: well, yes, there are two of us :/ Feb 25 13:45:27 rburton: I guess my point was just we do generate and track the data Feb 25 13:45:43 right just needs to be a bit more obvious Feb 25 13:45:45 not sure how to get people to look at/help with it though Feb 25 13:46:16 if the build complete mail included a breakdown of the ptest regressions and buildhistory output i'd be more likely to read yocto-builds Feb 25 13:47:15 rburton: there isn't a build completed email Feb 25 13:47:28 rburton: but yes, I take your point Feb 25 13:47:50 rburton: we already have the build completed QA email, its an evolution of that Feb 25 13:48:01 rburton: mostly a question of someone working on it Feb 25 13:48:30 I'm just frustrated as I know how nice this all would be, I've tried my damned hardest to get there :( Feb 25 13:48:39 sure, million things to do Feb 25 13:54:04 Is it possible to use RECIPE_MAINTAINER inside a .bb file or only for maintainers.inc ? Feb 25 14:00:23 PinkSnake: its just a variable, set it anywhere you wish Feb 25 14:00:27 for oe-core, in maintainers.inc Feb 25 14:00:37 but outside, whatever the layer policy is Feb 25 14:00:42 rburton thnak you Feb 25 14:12:10 RP: re-sent buildall-qemu with the typo corrected and a bit more justification in the commit message Feb 25 14:30:24 is there a reason why LAYERDIR isn't available outside of layer.conf? Feb 25 14:30:39 uhm, silly question Feb 25 14:30:46 Hi, is there a way to print out the currently used NAND ECC Configuration in Kernel and in Uboot? Feb 25 14:30:55 LAYERDIR is evaluted instantly and only when processing the layer.conf file.. so it's temporary Feb 25 14:30:55 it would be ambigous which layer it refers to.. Feb 25 14:31:06 if you need the contents in a later context, you will have to save them.. i.e. Feb 25 14:31:12 (layer.conf:) Feb 25 14:31:28 METAFOOBARPATH = "${LAYERDIR}" Feb 25 14:31:40 then you can refer to METAFOOBARPATH later, for that specific directory pth Feb 25 14:31:40 perdmann: if in doubt, dumping the registers from memory and reading the datasheets. :P Feb 25 14:31:40 thanks FrazerClews Feb 25 14:31:47 thanks fray* Feb 25 14:31:54 sorry for the accidental ping FrazerClews Feb 25 14:32:08 this is how COREBASE is defined by oe-core BTW.. Feb 25 14:33:03 LetoThe2nd ok ! Fine! in general i would be ok with this but even then iam not 100% sure that i use Hardware ECC, or am i wrong? Feb 25 14:33:45 LetoThe2nd sorry i start to get annoyed by this. #u-boot told me i should upgrade to mainline, it would work. It just prints more ECC errors, thats it :D Feb 25 14:33:56 perdmann: if the registers of the peripheral say so, i personally would be convinced. Feb 25 14:35:02 perdmann: but in the end, what you're just talking about is exactly the business of the board vendor. so i assume that you are basically working for one of such. Feb 25 14:35:04 is there a Linux / uboot command to read hardware registers? Feb 25 14:35:12 Hmm, still seeing reproducible builds complaining about a nonexistent deb path Feb 25 14:35:17 perdmann: linux has /dev/mem, uboot has md Feb 25 14:35:21 LetoThe2nd sadly iam not working for one of them ;) Feb 25 14:36:26 perdmann: well its kind of easy. if you bought a board from somebody which does work, go blame and demand the support you paid for. if you want to do something that is not explicitly supported, then you are a bit on your own. Feb 25 14:36:35 maybe i should get in contact with NXP. Their example is using raw NAND for the kernel Feb 25 14:37:39 right now its a modified eval board Feb 25 14:37:43 evil board :) Feb 25 14:44:02 How to build an image for a specific recipe? Feb 25 14:44:16 nacknick: the question does not make sense. Feb 25 14:44:48 LetoThe2nd Like `bitbake ` - but it does not make an image directory under work dir Feb 25 14:44:58 I want to get the final binary Feb 25 14:45:11 nacknick: then the recipe probably does not inherit core-image. Feb 25 14:45:58 when I run `bitbake core-image...` the recipe's image directory does exist Feb 25 14:46:33 nacknick: a recipe does not have an "image directory". Feb 25 14:46:57 nacknick: only image recipes specifically generate binary image outputs. Feb 25 14:47:36 Actually I have `raspberrypi3-linux-gnueabi///image/usr/bin` Feb 25 14:47:51 After running `bitbake core-image...` Feb 25 14:47:56 nacknick: that has nothing to do with an image per se. Feb 25 14:48:11 OK. But there I have the binary file that I need Feb 25 14:48:20 How should I create it without build the whole image? Feb 25 14:49:03 i guess you are just doing it wrong (TM) Feb 25 14:49:12 what is it that you *ACTUALLY* want to do? Feb 25 14:49:23 "TM"? Feb 25 14:50:08 I have a recipe that create a binary file for the final image. I want to get it without building the whole image (it just takes too long) Feb 25 14:50:27 creates Feb 25 14:50:38 in the simplest case, just grab it out of the build directory Feb 25 14:50:52 or out of the package directory, if you care about the install stage Feb 25 14:51:17 Do you familiar with WebOS? Feb 25 14:51:37 no Feb 25 14:58:12 nacknick: I'm familiar with webOS, but nothing you said is webOS specific Feb 25 14:58:43 nacknick: if you're working on some app and don't want to rebuild whole image you can use devtool to even deploy it to target with scp Feb 25 14:58:51 JaMa I thought maybe I get ipk file instead of the installed one Feb 25 14:59:13 nacknick: it needs a lot of expanding but https://wiki.yoctoproject.org/wiki/TipsAndTricks/DeployWithLocalPackageServer Feb 25 14:59:16 as you can scp the ipk from BUILD/deploy/ipk as well Feb 25 14:59:32 i so totally knew it was an xy question again. Feb 25 14:59:47 "i want to get the binary", and now its "i want the ipk" Feb 25 15:00:08 LetoThe2nd no. I don't want the ipk Feb 25 15:00:17 yeah, try to offer some good metal :) Feb 25 15:00:30 LetoThe2nd: fwiw, most recipes have an image/ directory as that's $D Feb 25 15:00:36 yes bad name :) Feb 25 15:00:41 I still want the binary. ELF file Feb 25 15:00:46 rburton: hrhr Feb 25 15:00:51 JaMa: need playlist suggestions? Feb 25 15:01:00 nacknick: no you *want* to update the binary on the target. Feb 25 15:01:11 LetoThe2nd: not me, but maybe nacknick would take it instead of binary Feb 25 15:01:16 rburton Actually I dont. Feb 25 15:01:18 nacknick: my link details the neatest way of doing it. or just scp the package as jama said Feb 25 15:01:28 "[14:50:06] I have a recipe that create a binary file for the final image. I want to get it without building the whole image (it just takes too long)" Feb 25 15:01:38 if you don't care for the target then just build that recipe Feb 25 15:01:47 I don't understand why people here decide for my what I want Feb 25 15:01:49 then extract it from the package Feb 25 15:01:54 nacknick: explain what you want then Feb 25 15:01:59 for me* Feb 25 15:02:06 we're all trying to guess what you actually want to do Feb 25 15:02:07 * LetoThe2nd goes back to *plonk* mode. Feb 25 15:02:15 I think I was pretty clear Feb 25 15:02:21 nacknick: because we're all just guessing what you actually want based on what you wrote.. Feb 25 15:03:00 There is an *image* directory for each recipe (inside *build/work*) Feb 25 15:03:24 you're going straight into the internals of how bitbake is building. what do you actually want to do. Feb 25 15:03:40 there is an image directory assuming the recipe was just built, was successful, and you don't use rm_work Feb 25 15:04:28 I just want to create that image for a specific recipe. When I run `bitbake ` it builds it, but apparently does not do one step to create that image dir Feb 25 15:04:51 because inside it, there is the ELF file that I need Feb 25 15:04:51 bitbake [recipename], the output is in tmp/deploy Feb 25 15:05:03 extract what you want from the packages in deploy Feb 25 15:05:25 because if you're using rm_work, or the packages came from sstate, there *is no image directory* Feb 25 15:05:34 its an intermediate directory that may or may not exist Feb 25 15:15:46 hello again Feb 25 15:15:54 you can force bitbake to re-create it and stop there (so that it isn't removed by rm_work) with bitbake -c cleansstate && bitbake -c install -f **** BEGIN LOGGING AT Tue Feb 25 15:26:37 2020 Feb 25 15:35:05 I'm having a few issues with devtool. 1st: "devtool add --srcbranch develop my-recipe git@gitlab.foo.com:bar/bar.git" seems to checkout the master branch. Any ideas why and how I can fix this? Feb 25 15:42:42 kroon: No, I haven't been working directly with douglas Feb 25 15:46:05 JaMa: -ccleansstate is such a heavy hammer though Feb 25 15:47:21 rburton: heavy metal hammer? Feb 25 15:49:07 rburton: depends on the app, but I agree Feb 25 15:49:51 math isn't strong today Feb 25 15:49:53 59 packets transmitted, 53 received, 10,1695% packet loss, time 58317ms Feb 25 15:51:24 ok, so what? Feb 25 15:56:08 YPTM: Armin is on Feb 25 15:56:19 Hey, everyone. I just started using yocto and built and fired up qemu. While it looking great first it now hangs quite a while during the boot (via ssh / nographics): Feb 25 15:56:46 hmm.. cannot copy paste. Feb 25 15:57:05 "A start job is runniing for dev-hda1.device" Feb 25 15:57:29 Could you give me a hint on why it is hanging there? Feb 25 15:58:54 YPTM: trevorw is on Feb 25 15:58:59 Emrius: sounds like it is trying to mount a drive that is not there. can you check /etc/fstab? i unfortunately have not much experience with qemu Feb 25 15:59:23 Emrius: off which poky version? which machine, etc? Feb 25 16:00:00 probably worth noting: this comes from mender as we plan device upgrades through mender Feb 25 16:00:02 marius@white-island:~/mender-qemu/build$ lsb_release -aNo LSB modules are available.Distributor ID: UbuntuDescription: Ubuntu 18.04.3 LTSRelease: 18.04Codename: bionic Feb 25 16:00:23 Emrius: nah , the poky version. Feb 25 16:00:40 Emrius: and the MACHINE that you are building for. Feb 25 16:00:44 yeah was just changing. Feb 25 16:00:47 warrior Feb 25 16:01:16 Emrius: so its poky + their layer? Feb 25 16:03:21 YPTM: khem is on Feb 25 16:03:24 Basically following this tutorial: https://docs.mender.io/2.3/artifacts/yocto-project/building Feb 25 16:03:46 So, yes, poky + their layer Feb 25 16:04:44 Emrius: and you're targetting qemux86-64? Feb 25 16:04:53 yes Feb 25 16:05:35 Emrius: then i'd say, take out their layer and try again. if its still broken then, we've got a possible bug. otherwise, they have. Feb 25 16:05:54 Ok. Thanks I'll try that! Feb 25 16:06:38 JPEW: wasn't there a video of a talk you did on reproducible builds Feb 25 16:07:05 YPTM: who was discussing OE selftest? Feb 25 16:07:22 alejandro Feb 25 16:07:29 thanks Feb 25 16:07:50 tlwoerner: do we have news on gsoc? Feb 25 16:08:01 LetoThe2nd: yes, we didn't get in :c Feb 25 16:08:10 tlwoerner: k Feb 25 16:08:34 tlwoerner: a particular reason you can tell, or basically just a "no"? Feb 25 16:09:27 just a no, unforunately Feb 25 16:09:42 i know some people i might be able to talk with to see if i can find out Feb 25 16:10:01 not because of me, please. Feb 25 16:10:12 LetoThe2nd: it'd be nice to know why Feb 25 16:10:16 200 groups were accepted Feb 25 16:15:07 YPTM: JaMa is on Feb 25 16:46:46 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13807 Feb 25 16:46:47 Bug 13807: enhancement, Undecided, ---, newcomer, NEW , Add support for elfutils debuginfod Feb 25 16:49:14 moto-timo: I've mentioned them in a few talks I've given, but not in depth Feb 25 16:49:29 moto-timo: I'm (hopefully) giving a talk about it at ELC this year Feb 25 16:49:48 moto-timo: thanks for the nomination! i have no idea what you nominated me for, lol ;-) Feb 25 16:52:17 RP: I'll take a look at psplash today Feb 25 16:52:45 smurray: thanks! Feb 25 16:55:14 zeddii: is https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1612 the kernel upgrade for 5.2? :/ Feb 25 16:55:58 zeddii: also https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/315 and https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1616? Feb 25 16:56:13 hello, is there any way to generate a compile_commands.json in a project I'm modifying with devtool? Feb 25 16:56:31 or ctags, or anything like that Feb 25 16:56:49 smurray: showed up twice on the last build run. Seems to only happen when the system is heavily loaded (full build from scratch) Feb 25 16:57:24 JPEW: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=d2934e65d600e87946bb74c3a611561e9a32a76d looks ok to you? Feb 25 16:57:47 RP: I guess that would perhaps slow down qemu for the test runs and make the race window bigger? Feb 25 16:57:55 RP: yep Feb 25 17:01:17 Hi Yocto team, I do have a questions concerning when creating a recipe where SRC_URI points to a pre-compile go binary. How is that bitbake will treat the binary on each tasks? For example, I can understand what would be do when do_fetch and do_unpack happens, however, when it comes to do_compile? I have checked the run.do_compile report and it looks like it does not do anything in that part whatsoever. Feb 25 17:01:57 smurray: yes Feb 25 17:02:03 *sigh* Feb 25 17:03:16 kovalevsky: for pre-compiled binaries perhaps inherit bin_package might be helpful Feb 25 17:04:54 ente: purely, upto you what you want to do in recipe, default is simply do_configure/compile/install Feb 25 17:05:29 In other instance, let's say I want to compile a go program that requires software at build time, this is assuming that I am building from raw source. In this case, if there is no recipe that would contain the required software to build the application, I will have to create one recipe that will build the sofware that it's required at building stage? If so, at the end when I am generating an image, the software required at build stage of my go Feb 25 17:05:29 application will generate an ipk or there is set variable that I can pass to bitbake to avoid the creationg of that ipk package? Feb 25 17:08:13 khem: well, in order to generate compile_commands.json at least in theory I need to inspect the build process in order to see how the compiler is being called, so I need to run something like do_compile within bear (or even better, make do_compile wrap the compile in bear) Feb 25 17:08:29 I'm guessing there's no tooling for that Feb 25 17:10:01 can I run do_compile from within a devshell or do I have to quit the devshell first? Feb 25 17:11:46 you can perhaps, devshell is just a shell with cross build env set Feb 25 17:16:09 RP: JPEW: my reproducibility issue was indeed because package_deb was not in the list Feb 25 17:29:23 so how would I start a build from within devshell? is that possible at all? Feb 25 17:36:39 not a proper build, but you can run make/etc to experiment Feb 25 17:40:22 can I find out what would be run in case of a proper build? Feb 25 17:40:46 tlwoerner: community advocacy, but as RP said it's a lot of work for one person Feb 25 17:41:05 JPEW: I'm confusing your other talks :) Feb 25 17:41:32 I mean it sets $CC and so on, but I still don't know what arguments it passes to, say, ./configure in case of an autotools based package, or to cmake in case of a cmake based package Feb 25 17:49:41 ente: temp/run.do_configure etc Feb 25 17:50:14 rburton: I don't see a temp, neither in the directory devshell drops me in nor in ../temp like the internet say Feb 25 17:50:17 s Feb 25 17:50:42 tgamblin: we should fix that issue though as it shouldn't break like that Feb 25 17:50:58 RP: yeah, I'm gonna take a look at it Feb 25 17:51:29 RP: Good news is that there don't seem to be any reproducibility issues related to coreutils-ptest anymore, so I can finally resubmit that shortly Feb 25 17:52:53 tgamblin: great! Feb 25 17:55:45 found a run.do_configure etc in tmp/work/armv6*/pkgname/pkgver/temp, thx Feb 25 18:01:07 tgamblin: Ya, that's strange. The test should always build deb and ipk Feb 25 18:12:29 moto-timo: what's involved? Feb 25 18:21:23 RP: core-image-sato-sdk-ptest takes 8hrs on qemumips, but it does finish :) Feb 25 18:35:21 khem: nice :) Feb 25 18:49:23 anyone seeing poky/meta/recipes-support/pinentry/pinentry_1.1.0.bb:do_configure failures after update today? sh: 1: arithmetic expression: expecting EOF: "0xbran" Feb 25 18:54:59 RP I cherry-picked some unsent patches from AUH, the more easy ones. Just one last batch before feature freeze :) Feb 25 18:57:20 kanavin_home: sounds good, thanks Feb 25 18:58:25 and thanks for the mention in the status mail Feb 25 18:58:43 kanavin_home: its good work :) Feb 25 18:58:58 kanavin_home: I wasn't sure we'd reach this point to be honest! Feb 25 18:59:14 RP I wish we could enforce a failure, as in the absence of that ptests are likely to slowly erode again Feb 25 19:08:51 RP: yeah, I could have gotten more results but webkitgtk change to enable GI fired back and my builds were hung all night. I sent a fix for it Feb 25 19:09:07 I am sure qemuarm spends approx same time Feb 25 19:10:12 RP: http://ix.io/2cA1 Feb 25 19:12:04 khem: on the AB arm sdk-ptest takes 2.5 hours, but it runs on ARM hardware with kvm or what is it called there. Similar time to x86. Feb 25 19:14:33 yeah kvm is a different story I know **** ENDING LOGGING AT Tue Feb 25 19:26:28 2020 **** BEGIN LOGGING AT Wed Feb 26 12:53:04 2020 Feb 26 13:00:05 Is it okay to use OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "/usr/bin" like this ? Feb 26 13:01:26 dev1990: no idea, whats the actual use case? Feb 26 13:01:52 cmake not finding native tools like git Feb 26 13:03:00 even if DEPENDS += "git-native" i get | -- Could NOT find Git (missing: GIT_EXECUTABLE) Feb 26 13:03:25 not sure if this is workaround or acctual proper way Feb 26 13:04:42 hum that sounds very very much like cmake reaching into the host instead the hosttools directory. Feb 26 13:05:03 or maybe this is cmake project file fault, but I found that kodi and dolphin-emu is affected the same way Feb 26 13:05:33 * LetoThe2nd puts his bet onto cmake project file trying to be clever Feb 26 13:12:04 dev1990: maybe the cmake project file is searching for /usr/bin/git. check what the cmake module does. after git-native in DEPENDS, git is in the build env. Feb 26 13:12:30 yeah, hooray for hardcoded pathes. Feb 26 13:19:31 ok i tried to read out the Registers but my board always hangs when i try to read thos registers Feb 26 13:19:37 any suggestions? Feb 26 13:21:29 I found that cmake project using GIT_EXECUTABLE variable, but no one setting this (https://pastebin.com/pbRgiRJe) Feb 26 13:21:43 perdmann: You probably need to give more context there Feb 26 13:21:46 this cmake project is pretty complicated anyway (https://github.com/xbmc/xbmc) Feb 26 13:26:05 https://cmake.org/cmake/help/v3.0/module/FindGit.html should define this and there is no FindGit invoke in xbmc(kodi) cmake, this is strange Feb 26 13:27:37 well, I'll create a issue in xbmc tracker, maybe they will explain how it's working Feb 26 13:44:03 Hi is there a possibility to prevent wic from creating a certain mount point in /etc/fstab but still have the partition in the image? Feb 26 13:44:40 fl0v0: i don't think wic creates the fstab, but it rather is what you supply Feb 26 13:48:07 LetoThe2nd: ah found it. It adds the entry to fstab if you provide a mountpoint Feb 26 13:48:13 https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#command-part-or-partition Feb 26 13:48:26 New news from stackoverflow: Native step in a non native yocto recipe || SSH : Problem while setting up a remote Linux connection Feb 26 13:48:51 fl0v0: interesting. thanks. Feb 26 14:18:31 New news from stackoverflow: Native step in a non native yocto recipe [closed] Feb 26 14:21:20 ^^ Perfect example of why I don't answer things on Stack Overflow - that was a valid question and just gets closed as it didn't have "details" Feb 26 14:22:39 * paulbarker adds yocti to my kill file Feb 26 14:26:01 paulbarker: add SO to killfille :) Feb 26 14:28:50 adding a comment just to spite SO Feb 26 14:30:06 rburton: hrhrhr Feb 26 14:30:17 damnit you can't put new lines in comments Feb 26 14:30:38 rburton: i also kinda like the ssh problem one. Feb 26 14:30:42 Hey all, I'm trying to create a recipe that in the Makefile requires docker to build. I've added `DEPENDS = 'docker-ce'` but when building I'm still getting: `| time="2020-02-26T14:28:07Z" level=fatal msg="exec: \"docker\": executable file not found in $PATH"` Feb 26 14:30:57 rburton: obviously didn't like my answer here a couple of minutes before. Feb 26 14:31:12 RP: so I think I have a fix in hand for the psplash race, slight issue is there are other new changes in psplash.git that it's unclear how we want to handle if we bump SRCREV Feb 26 14:31:21 Nathan2231: you probably mean "docker-ce-native Feb 26 14:31:35 Nathan2231: and, in reality, i guess you * Feb 26 14:31:38 RP: i.e. one of the generated images' .h files was removed, so will always be regenerated Feb 26 14:31:49 *ACTUALLY* mean to get rid of docker, but... its a close second :) Feb 26 14:32:46 Haha. That's a good point. But there doesn't seem to be a docker-ce-native Feb 26 14:33:02 Nathan2231: recipe writing time for you, then. Feb 26 14:33:20 Nathan2231: but seriously, such a build process is completely busted. Feb 26 14:33:34 Nathan2231: that's not going to be particularly workable, since docker needs its daemon running to be able to do anything Feb 26 14:33:59 Nathan2231: as it would require the build to be effectively root, and not be contained in any form any more. Feb 26 14:34:51 Nathan2231: so your best bet is to rather have a build pipeline that, in whichever form, creates binary artifacts, which you package through a recipe in turn then Feb 26 14:35:33 as an example, the docker build typically wants to run inside docker, but meta-virtualization goes to great pains to avoid doing that Feb 26 14:36:02 * LetoThe2nd rephrases: "completely busted" Feb 26 14:36:32 Well that's unfortunate... Feb 26 14:42:41 LetoThe2nd: Alright as an alternative to docker-ce I can use go-native to build. But I'm getting `error setting certificate verify locations:` in the go build. Any idea? Feb 26 14:43:03 Nathan2231: nope. Feb 26 14:45:34 Nathan2231: I've solved runtime CA problems with golang packages in the past by adding ca-certificates to the recipe DEPENDS... not sure about build, maybe ca-certificates-native? Feb 26 14:46:44 my impression is that all those fancy application package managers are the absolutely utmost PITA when it comes to the reproductible-crosscompilation situation. Feb 26 14:48:39 New news from stackoverflow: Why is this ptvsd package failing to compile? Feb 26 14:54:54 https://www.irccloud.com/pastebin/kz0ZP8xj/ Feb 26 14:56:05 bernardoaraujo_: Thanks, I'll give it a go and let you know! Feb 26 14:56:45 welcome! Feb 26 14:56:50 my turn: Feb 26 14:56:54 how to make sure the user is able to access man pages? I noticed ${PN}-doc packages (when available) contain the man pages, but I can't figure out how to make sure my image installs ${PN}-doc for all packages that provide that option Feb 26 14:59:01 bernardoaraujo_: I think you can add doc-pkgs to IMAGE_FEATURES. Check the manuals for the exact syntax Feb 26 14:59:37 paulbarker: ++ Feb 26 15:00:10 https://www.yoctoproject.org/docs/3.0/mega-manual/mega-manual.html#ref-features-image Feb 26 15:00:17 although, users and manuals, thats generally a way more psychological than a technical issue.... Feb 26 15:00:20 Feb 26 15:08:19 bernardoaraujo_: Unfortunately no dice. On closer look at the logs it appears to be setting the CAfile in a nonexistent directory Feb 26 15:08:25 LetoThe2nd: exactly! I wanna make sure I can say RTFM, kinda like paul should have told me Feb 26 15:08:34 paulbarker: thanks, works like a charm! Feb 26 15:08:40 bernardoaraujo_: hrhr Feb 26 15:18:45 New news from stackoverflow: setxkbmap equivalent in a Yocto Project based Distro Feb 26 17:29:13 RP: I think the utils.bbclass patch on master-next is causing https://errors.yoctoproject.org/Errors/Details/392780/ Feb 26 18:13:53 RP: I wonder if https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xorg-lib/libxaw_1.0.13.bb symlinks are issue Feb 26 19:47:36 I've got an odd QA failure I am stuck on. Working on openbmc and we're still using some python2 stuff and we're in the process of moving it over to python3. Feb 26 19:47:59 There is one recipe that both uses python3 as part of the build (to generate code) and installs a python script into the target. Feb 26 19:48:21 It DEPENDS on both python3 and python3-native and RDEPENDS on python3-core. Feb 26 19:49:26 I end up with something like: QA Issue: /usr/bin/sdbus++ contained in package sdbus++ requires .../recipe-sysroot-native/usr/bin/python3-native/python3, but no providers found in RDEPENDS_sdbus++ Feb 26 19:49:53 When I look at the RPM, it does indeed have a dependency on the *native* python3 even though it is a target package. Feb 26 19:50:25 rpm -qpR sdbus++-1.0+git0+67c79b0ca6-r1.arm1176jzs.rpm shows .../recipe-sysroot-native/usr/bin/python3-native/python3 Feb 26 19:50:38 Prior to the python3 conversion it showed '/usr/bin/env'. Feb 26 19:51:02 stwcx: perhaps its build process is grabbing the path to python3 and sticking it into a script's shebang line? Feb 26 19:51:34 smurray: I don't think so, but let me 100% confirm that is *not* the case. Feb 26 19:51:50 The original script (in source) has a #!/usr/bin/env python3 Feb 26 19:53:12 I guess try grepping for recipe-sysroot-native in everything in the WORKDIR/package directory, to see if it's getting into something Feb 26 19:53:26 Oh, wow. When I look at packages-split/sdbus++ it does indeed have a replaced she-bang!! Feb 26 19:54:21 heh, now you just have to figure out how that happened Feb 26 19:54:36 Yeah. Would 'inherit python3native' be causing it somehow? Feb 26 19:55:04 not that I can think of, it just sets a few variables iirc Feb 26 19:55:15 Agreed to my recollection too. Feb 26 19:56:04 seems more likely there's logic in the package makefiles, etc. that's trying to be overly clever Feb 26 19:57:23 It seems to be using some mix of autotools and python-setuptools... I wonder if setuptools is doing it. Feb 26 19:57:46 There's nothing in the autotools/makefile that would be doing it. Feb 26 19:57:58 Thanks though. That gives me something to look at at least. Feb 26 19:58:13 stwcx: no worries, good luck Feb 26 20:07:46 Turns out there is a reported issue with pypa/setuptools on this and OE has some workarounds referenced right in the issue. https://github.com/pypa/setuptools/issues/494. Feb 26 20:07:53 Hopefully I can just do some magic "inherit distutils3" incantation and it'll all be solved. My only trouble is that this is a autotools and distutils3 is meant to be for "standalone" python packages. Feb 26 20:19:43 New news from stackoverflow: Cannot get matchbox-keyboard to display on kiosk touchscreen Feb 26 20:32:26 smurray: Thanks again for the help. I just needed another brain to point me in a direction. :) I was able to port the distutils3 workarounds into our autotools+python bbclass. Feb 26 20:32:39 stwcx: cool Feb 26 21:56:34 what is the main difference between 'BitBake-Style Python Functions' and 'Python Functions' in bitbake? Feb 26 21:58:09 Piraty: nope, still alive, =) Feb 26 22:03:17 mischief: are you comparing functions defined with 'def' to those defined in the usual function syntax? Feb 26 22:07:24 kergoth: yes. what's the difference? Feb 26 22:23:07 def form can be nested Feb 26 22:23:42 and a local function inside function can be used Feb 26 23:01:42 khem: how would i call a python function from a shell task? Feb 26 23:04:03 you can't directly. that is, you can use ${@} to call a def'd python function from there, but it'll be run at expansion time, not the time the task runs Feb 26 23:04:31 :-( Feb 26 23:04:58 still does the job more often than not, depends on exactly what you're trying to do Feb 26 23:05:25 well, i am building something :-) Feb 26 23:05:40 i could try to do it as a shell task i suppose Feb 26 23:05:42 there are a number of options. you could split off a standalone python script and call that, if it doesn't need metadata access, for example Feb 26 23:09:39 kergoth: ah, no. i do need access to some variables, and passing them all as cli args seems mildly painful Feb 26 23:10:30 basically i need to template a large string. my thought was to use python's builtin templating Feb 26 23:10:38 a heredoc might work instead.. Feb 26 23:13:02 could do that, iv'e used def'd functions that emit metadata variables in a shell syntax or '| while read' syntax before to do that sort of thing Feb 26 23:13:11 could also emit a subsection of hte metadata as json.. Feb 26 23:13:30 or just write your main task as python and have it bb.build.exec_func() the shell part and the python part, or write hte whole thing in python, or.. Feb 26 23:13:30 :) Feb 26 23:13:59 kergoth: one problem is that this is inside an existing task Feb 26 23:14:00 downside to yocto/oe, flexible, but always so many ways you could do things..and it's not always obvious which is the cleanest Feb 26 23:14:06 specifically an image conversion task :\ Feb 26 23:14:26 i.e. this lives inside CONVERSION_CMD Feb 26 23:14:33 ah, and that's expanded directly, not run via exec_func.. Feb 26 23:17:20 mischief: https://gist.github.com/kergoth/09de93347bb62238ad5bede58e41bcd4 hacky, admittedly, but.. needs must Feb 26 23:17:37 really depends on how many variables are needed, not all approaches would scale well Feb 26 23:20:19 New news from stackoverflow: gconftool-2 missing [Yocto] Feb 27 02:58:55 finally **** ENDING LOGGING AT Thu Feb 27 02:59:58 2020