**** BEGIN LOGGING AT Mon Oct 21 02:59:58 2019 Oct 21 06:04:59 Devicetrees on intel EFI platforms - anyone with experience with that? Oct 21 06:13:49 bojones: i can't remember it being mentioned here so far. Oct 21 06:17:08 LetoThe2nd, thanks **** BEGIN LOGGING AT Mon Oct 21 06:44:26 2019 Oct 21 06:45:42 Hello, i have figured out what python modules and packages I don't need. I can save 20 MB space for now. In what location I should list these python modules and packages to prevent yhem bein added to the final image? Oct 21 06:46:13 abhiarora44: well don't add them to IMAGE_INSTALL Oct 21 06:46:22 Someone suggested BAD_RECOMMENDATION. please help me with location of the file/recipe in which it should be added. Oct 21 06:46:30 *sigh* Oct 21 06:48:50 IMAGE_INSTALL adds python3-core, python3-email.... Etc. Oct 21 06:48:51 However, these pulls various python modules and packages. Only subset is needed for my application. Like removing setuptools, lub2to3, pip, disutils is required. However, IMAGE_INSTALL lists python3-core etc... Oct 21 06:49:13 i repeat: then do not write those things into IMAGE_ISNTALL Oct 21 06:50:48 I got you sir. But my IMAGE_INSTALL doesn't add the packages I want to remove. Are you saying these small modules & packages are being added somewhere? Oct 21 06:50:49 or even better, do not write ANYTHING into IMAGE_INSTALL, and only list in the DEPENDS of your application what you need. Oct 21 06:51:27 my IMAGE_INSTALL https://usercontent.irccloud-cdn.com/file/Cw5SCZMP/irccloudcapture1913995326.jpg Oct 21 06:51:48 seeriously, we are getting nowhere that way Oct 21 06:52:03 (and why for godssake a jpg?!?) Oct 21 06:52:14 The modules that I want to remove are not being listed but still they are pulled in by above statements. Oct 21 06:52:29 hello folks Oct 21 06:52:58 if I want to have a class of mine to overlay a class of another layer, I do need to list my layer before the other layer, if a recipe of that other lay makes use of the class, right? Oct 21 06:53:09 abhiarora44: and which of those lines adds the undesired things? why is it there then? and, really, those things belong into the DEPENDS of your application Oct 21 06:53:24 because at the time of use, my layer need to have been read-in already. Oct 21 06:53:24 litb: its ordering dependent, right Oct 21 06:53:47 ah. I suspect I will split-up my layer then. into one "overlaying" layer and then the actual content layer Oct 21 06:54:19 I am manually copying my python application. Oct 21 06:54:46 abhiarora44: then it might be a *VERY* *GOOD* idea to start chaging that now. Oct 21 06:56:02 One more question, can I use individual python modules/packages in DEPENDS of my application? Oct 21 06:56:20 abhiarora44: if they are seperate packages, yes. Oct 21 06:56:54 Or I have to use things like python3-core, python3-misc. I am not sure what they pulls. Oct 21 06:57:29 abhiarora44: its all about packaging. its the same things you write into IMAGE_INSTALL and DEPENDS Oct 21 06:58:06 abhiarora44: the package management of yocto does not know the internal package structure of those pyhton things. so it might be that you have to split up some things, or whatever. Oct 21 06:58:27 LetoThe2nd, is it considered an error to have an overlay layer as first layer in BBLAYERS, if the layer is intended to overlay classes of another layer, and I specify that other layer as a LAYERDEPENDS ? Oct 21 07:00:07 generally the appraoch should be 1) create your application layer 2) add the needed things into DEPENDS. 3) if those thigns are too big, look at the recipes that provide them and see if they can be reduced. Oct 21 07:01:57 abhiarora44: because the -misc package is maybe not a collection, but jut a really big package. i don't know, i'm no python guy. so if your project requires reducing it, you might need to split the packageing process up Oct 21 07:02:17 DEPENDS must use recipe names, not package names AFAIK Oct 21 07:02:56 litb: no. Oct 21 07:03:00 oh Oct 21 07:03:26 @LetoThe2nd: that's where I am confused. I want to know where are the recipes that pulls things like python3-core and how they do that, then may be add my own package like python3-myown which pulls particular files from online and have an recipe for application which depends upon my python3-myown Oct 21 07:04:10 but the manual says "DEPENDS is a list of recipe names. Or, to be more precise, it is a list of PROVIDES names, which usually match recipe names. " Oct 21 07:04:28 abhiarora44: i already pointed out that oe-pkgdata-util can tell you all of that Oct 21 07:05:05 litb: see, thats a difference Oct 21 07:05:41 Yes, I'm in error. But half of what I said is true >< Oct 21 07:06:01 litb: if it makes you feel better, then "ok, you are half right." ;) Oct 21 07:06:41 abhiarora44, you can also say "bitbake -g " or the recipe that you build and that happens to "strangely" build python3-core" Oct 21 07:07:01 and then use oe-depends-blah (forgot the name of that util). with that you can finid out why python3-core is built Oct 21 07:07:28 that's how I'm developing my mingw target layer and eliminate the need to build bash and base-files and so on Oct 21 07:14:56 Got it. But I also want to know what python modules python3-core pulls. Oct 21 07:15:38 Will try oe-pkgdata-util again. Oct 21 07:16:22 Pardon for newbies questions. It's a bit hard to understand how to get information you need from yocto for me. Oct 21 07:17:58 abhiarora44: its all fine, but you need to leave some assumptions behind, and thats the hard part. Oct 21 07:20:26 Just want to clarify one point. Things like python3-core is purely yocto entity? They exist in yocto world only and yocto has some list somewhere which lists what to pull from where? Oct 21 07:20:52 yes. Oct 21 07:21:04 same for python3-misc, for example Oct 21 07:23:38 there's a tool in devtool add that scans python packages for imported modules and transforms them to yocto package names Oct 21 07:23:59 I don't know whether this scanner can be used in isolation to scan python code and print out used packages Oct 21 07:27:00 thats not exactly a yocto specific technique, as far as i can see: https://stackoverflow.com/questions/9232568/identifying-the-dependency-relationship-for-python-packages-installed-with-pip Oct 21 07:29:14 hi, I'm seeing bitbake hang on zeus due to circular dependency problems. any ideas how to debug these and find out where the loop is? Only hint to problems is the hanging bitbake process with warning "Identifying dependency loops (this may take a short while)..." Oct 21 07:32:54 mcfrisk, for me, i'm on warrior, and I did have dependency loops between gettext and glib. Oct 21 07:33:20 mcfrisk, before it printed the loops, it said "enable debug flags to see packaqes involved", or something similar Oct 21 07:33:31 maybe those flags can help identify the problem? Oct 21 07:40:12 litb: ok, I'll need to check each loop which eventually gets printed. just got "Initialising tasks...ERROR: 495 unbuildable tasks were found" until now but after 10 minutes something was printed out. Oct 21 07:40:54 some bbappend and class change is now triggering this but can't yet tell which one.. Oct 21 07:43:37 hm, I remember I did "A_override += 'foo'" at one time, and it had some bad effects. I can't remember what it was Oct 21 07:44:12 I think it did override another "A += 'foo'", but I'm not sure whether it's even possible to override immediate appends like that Oct 21 07:45:24 good morning Oct 21 07:47:04 mckoan: not sure about that. Oct 21 07:50:16 LetoThe2nd: if they are only yocto entity, then i should be able to find what yocto does when it sees python3-core and python3-misc. I will also try tools that you have suggested but grep is what I can do quickly Oct 21 07:50:56 abhiarora44: like i said, i think i even sent you the very lines that show how -misc is created on the mailing list Oct 21 07:51:33 abhiarora44: and oe-pkkdata-util certainly can tell you a lot about the resulting packages Oct 21 07:56:29 LetoThe2nd: If I may shime in, I found this file interesting: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json explicit all the RDEPENDS of python packages which are not explicitly declared in bb files Oct 21 07:57:29 not exactly on point with the discussion but thought it was worth mentioning Oct 21 07:59:39 qschulz: it is certainly helpful! my knowledge is only generic, and not on python in any way as i avoid it Oct 21 08:06:43 Hello, I have a question about the packaging of sources for out-tree kernel module. The sources do not seem properly packaged, unless there is a trick? Oct 21 08:07:11 tprrt: why should sources be packaged at all? Oct 21 08:08:28 New news from stackoverflow: Yocto doesn't copy libphp7.so to rootfs Oct 21 08:08:28 LetoThe2nd: I mean in the "-src" package to debug Oct 21 08:11:33 tprrt: you can have a look with bitbake -e virtual/kernel, search for FILES_${PN}-src. That's what's used for filling the -src package. If there are missing paths, they need to be added. Also, any file matched by 2+ FILES variable will only appear in the first package that is.. packaged. Oct 21 08:13:42 LetoThe2nd: for the SO question, *.so are not packaged in the normal package but in the -dev package. Only the lib*.so.* (note the dot after so) libs are packaged in "normal" pacjkage Oct 21 08:14:21 http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n299 Oct 21 08:14:28 http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n314 Oct 21 08:14:34 qschulz: ah great, please correct me there! Oct 21 08:15:11 qschulz: thx, I will check if FILES_${PN}-src is correctly set. Oct 21 08:37:25 LetoThe2nd: totally agree. Even worse, flooded everywhere here :-( Oct 21 08:37:43 mckoan: huh? Oct 21 08:47:06 LetoThe2nd: your answer to the good morning of mckoan an hour ago :) Oct 21 08:47:41 yes thats clear, but i'm suprised that he feels flooded. Oct 21 08:48:54 LetoThe2nd: I mean streets aroud are flooded Oct 21 08:50:14 mckoan: strange, didn't get any news about it. Oct 21 08:51:24 LetoThe2nd: https://www.corriere.it/ Oct 21 08:52:12 mckoan: hmm :-/ Oct 21 08:53:12 mckoan: ah https://www.tagesschau.de/ausland/italien-unwetter-121.html Oct 21 08:53:24 mckoan: didn't get much news, weekend with kids and all. Oct 21 09:05:57 oh wow, gl! Oct 21 09:07:37 hm, I need to use the ${var##*} bash syntax. how can I prevent yocto from messing with it? Oct 21 09:08:15 litb: compilcated, i think yocto bash parser is not exactly...bash Oct 21 09:08:50 since it's used only for variable expansion in yocto, I hope yocto won't touch that bash syntax though ? Oct 21 09:08:59 i'll find out Oct 21 09:14:23 there was something on the ml lately. maybe i can find it Oct 21 09:18:16 nope, sorry. Oct 21 09:32:31 LetoThe2nd: Isn't the shell used to run the tasks is the one default on your system? I don't remember exactly but I think it's using sh from the host? Oct 21 09:32:58 qschulz: possibly. i don't know enough about it to comment properly Oct 21 09:37:19 litb: can you write a script outside of a class file to execute instead? you can't assume bitbake sh funcs run in bash anyway Oct 21 09:38:47 rburton, ah I see, thanks! Oct 21 09:41:22 rburton, I avoid [[ and any other bashisms. However ${##} and %% operators are not listed as bashisms as far as I can see. not sure Oct 21 09:41:55 unfortunately bitbake uses ${} so that makes using advanced expressions 'tricky' Oct 21 09:42:14 i guess the parser should check that the contents are just alphanumeric and pass through if not Oct 21 09:42:43 hm, I see Oct 21 09:53:31 Hi folks. Is there any standard way for deploying a dtsi / including it in devicetree? Oct 21 09:53:43 huh? Oct 21 09:54:05 maybe it works similarly to kernel config snippets Oct 21 09:54:11 frosteyes: a dtsi cannot be deployed independently, its not meant for that Oct 21 09:54:32 frosteyes: a dts file is meant to include it at build time. the resulting dtb is to be deployed. Oct 21 09:54:57 My situation is that I have created a recipe for something I call "mem-layout" it is from a git archive, whers it contains a spec and some python code for generating dtsi, header and c files etc. Oct 21 09:55:26 My devicetree depend on mem-layout and will include it. Oct 21 09:56:07 well then whats the point? Oct 21 09:57:29 At least this is the plan.. Oct 21 09:59:23 Currently I have created a "do_compile()" in the recipe for generating the dtsi, etc. but is strugling on how to provide it for devicetree. Oct 21 09:59:56 So more if any have worked with devicetree's where the needed to include dtsi from the outside.. Oct 21 10:00:01 the recipe providing the final dtb probably has to provide virtual/kernel-devicetree or something Oct 21 10:00:02 maybe he's trying to "deploy" the files from that recipe as input to a different recipe? Oct 21 10:00:14 litb: yes Oct 21 10:00:23 I think the correct way to do this is using recipe-sysroot functionality? Oct 21 10:00:25 frosteyes: well what builds the *ACTUAL* devicetree? Oct 21 10:01:24 frosteyes: because thats the real question. Oct 21 10:01:25 A seperate recipe "devicetree" Oct 21 10:01:34 rburton, cheers (re: license per image work) Oct 21 10:01:48 rburton, I honestly don't remember about python and glib ptests Oct 21 10:02:07 rburton, so which way should we go with sysprof? add polkit to core or add sysprof to meta-oe? Oct 21 10:02:08 frosteyes: so your problem is to pass a build artifact from one recipe to the next one? Oct 21 10:02:28 kanavin: i'm leaning towards polkit in core, as systemd wants to use it a lot too Oct 21 10:03:15 Is the plan... The reason is that the devicetree is a bit complex. It is a ZynqMP device where you have the processor subsystem configuration from the HDF, the FPGA part, so I end up with a number of dtsi to combing it for the devicetree. Oct 21 10:03:26 LetoThe2nd: yes. Oct 21 10:03:28 in addition to FILES_SOLIBSDEV, there should be a FILES_SOLIBS that instead of being ${libdir}/lib*${SOLIBS} is ${bindir}/lib*${SOLIBS} Oct 21 10:04:28 and ideally a SOLIBSDIR that's either ${bindir} or ${libdir}, depending on presence of mingw32 machine. also BASE_SOLIBSDIR . I think many packages can make use of that and will avoid a .bbappend in the meta-mingw layer Oct 21 10:04:43 So I want the devicetree to depend on the needed "subcomponents", and pass the dtsi as an artifact for the devicetree.. Oct 21 10:04:46 frosteyes: well then i'd probably make the dtsi generation a -native recipe, have the devicetree generation recipe depend on iit and be done. or, pour both into a bigger one. Oct 21 10:05:37 LetoThe2nd: Thanks. will look into the -native recipe and this part.. Oct 21 10:06:06 frosteyes: in a nutshell, native means shall run on the dev host and not be crosscompiled/deployed. Oct 21 10:07:08 This was execatly what I was looking for. Just did not know the terminology Oct 21 10:07:10 frosteyes, AFAIK, you need to install the dtsi into one of the dirs listed in SYSROOT_DIRS_NATIVE or stage your files manually in SYSROOT_PREPROCESS_FUNCS Oct 21 10:07:26 then you can just DEPENDS on your native recipe from the final DTB recipe Oct 21 10:07:34 litb: that was the other part I needed. Oct 21 10:07:47 You are the greatest... Oct 21 10:08:09 frosteyes: i know, but thanks for the confirmation! Oct 21 10:08:10 Yocto is cool, but it takes some time to learn it :) Oct 21 10:13:37 LetoThe2nd: SO question turned out a little simpler (most probably missing php-modphp in IMAGE_INSTALL) but still explained the whole FILES and .so* thing anyway Oct 21 10:14:12 qschulz: hrhrhr Oct 21 10:14:35 qschulz: almost a classic "wtf is this IMAGE_INSTALL, lets just add a rootfs postpropcessing command!" Oct 21 10:43:40 kanavin: agreed on polkit fwiw Oct 21 10:43:48 kanavin: and the license stuff is cool :) Oct 21 11:28:21 hallo. Would perlbrew not work in yocto? as in "install and switch to older perl version, then bitbake ? Oct 21 11:29:05 I don't know, where does it takes the perl path from? Oct 21 11:30:22 kayterina: looks like some runtime package management thing. headaches ahead. Oct 21 11:39:10 New news from stackoverflow: raspberry pi3 can not launch application on primary HDMI Display, can launch on remote using ssh -x Oct 21 12:14:13 I'm in the process of upgrading from Sumo to Warrior. After the upgrade, I'm missing some archiver source packages that used to be generated in Sumo. For example, I no longer see a source package for bzip2. Any idea why? Oct 21 12:15:23 Correction: source tarball; not source package Oct 21 12:17:19 hey guys, I was wondering if someone knows what the actual task is that copies the images from ${IMGDEPLOYDIR} to ${DEPLOY_DIR_IMAGE}? I try to add some additional symlinks and thought this could be done by simply adding them to ${IMGDEPLOYDIR}. Oct 21 12:20:13 bisbarn: bad idea, rather make them into a simple package for reproductibility purposes Oct 21 12:21:32 bisbarn: sstate-cache of do_image_complete of your image recipe https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n278 and following line Oct 21 12:22:42 If I'm not mistaken, writting to non sstate-cache'd dir of the task where you're doing things with the dir is not the best idea Oct 21 12:23:35 so the symlinking could be done in IMAGE_POSTPROCESS_COMMAND actually because of https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n270 Oct 21 12:23:49 sounds awful, to be honest Oct 21 12:24:11 this ist stuff that nobody who looks at your recipes will understand without thinking at least twice Oct 21 12:24:31 mmhhh, basically i just want to add a "release" dir within ${DEPLOY_DIR_IMAGE} and add some symlinks (or cp) for the images with a version tag in addition, is there a best practice for this? Oct 21 12:25:17 ah thats what you mean. ok forget everything i said then. Oct 21 12:25:55 (i read it as "add symlinks into the image, in some form of postprocessing step") Oct 21 12:27:01 :) Oct 21 12:27:32 qschulz: are the images already copied into ${DEPLOY_DIR_IMAGE} when the IMAGE_POSTPROCESS_COMMANDs run? Oct 21 12:28:48 I was able to easily patch the kernel in my build by generating a patch file and adding to SRC_URI+=. Oct 21 12:29:02 * alessioigor waves all, I have a package that install files and directories (like bin, sbin, usr and so on) into the image directory. The same recipe in -native install /home/alessio.bogani/WIP[a very long host path] into image directory. What I have made wrong? Oct 21 12:33:00 I'd like to do that same thing with u-boot, but I'm having trouble finding which SRCREV to make my diffs against. Oct 21 12:33:32 ecdhe: bitbake -e your u-boot and grep for ^SRCREV Oct 21 12:33:41 bisbarn: I don't think no. You write to sstate-inputdirs in the task and the sstate-cache takes that and write it to the sstate-outputdirs is what I guessed. So same as you would do in a do_install where you install in ${D} and not in the actual rootfs, I would try to do the symlink in IMGDEPLOYDIR directly and see what happens Oct 21 12:33:50 LetoThe2nd: My uboot recipe uses AUTOINC, will that still work? Oct 21 12:35:22 ecdhe: if you tell your recipe to exlicitly always use latest HEAD, then it obviously will not have a specific SRCREV, right? Oct 21 12:36:08 LetoThe2nd: granted Oct 21 12:36:29 ecdhe: use devtool Oct 21 12:42:21 you'll get the sources directly, patched and everything. Work on top of the sources in the workspace, create the patches, update the recipe, devtool reset, you're done :) Oct 21 12:49:15 qschulz: good word, taking a look at this now Oct 21 12:52:07 qschulz: for a workflow, do i still want to modify code, generate patches, and include them in SRC_URI? Or can I modify code and use it directly? I'm just adding printfs to debug a problem so I'm not worried about strict source control Oct 21 12:52:50 ecdhe: during the debug phase of things like u-boot, i usually recommend to just not use yocto/oe, but build manually. Oct 21 12:53:03 ecdhe: use devtool, until you devtool reset, Yocto is going to use the sources (even non commited) in the workspace of devtool Oct 21 13:12:15 qschulz: allright IMAGE_POSTPROCESS_COMMAND works. My previous task ran after do_image I guess that was the issue. If i understand it correctly do_image_complete runs after do_image and thus in parallel to my own task. Oct 21 13:14:28 I'm not that happy with IMAGE_POSTPROCESS_COMMAND I'd rather use a task, currently trying to add the task with before do_image_complete Oct 21 13:14:31 the thing is, if you don't use the sstate-cache'd dirs, you'll run into problems later Oct 21 13:14:51 git status Oct 21 13:14:51 when you clean something or Yocto retriggers some functions Oct 21 13:15:15 fatal: not a git repository Oct 21 13:15:28 qschulz: git beer? Oct 21 13:15:38 yeah I allways wanted to use IMGDEPLOYDIR, but as I said since my task ran in parallel it didn't copy it over to DEPLOY_DIR_IMAGE ;) Oct 21 13:16:15 IMGDEPLOYDIR is sstate-cache'd in do_image_complete, not in other tasks Oct 21 13:16:49 ahhh now I understand Oct 21 13:17:06 well than I'll stick with the postprocess command, thank you ;) Oct 21 13:17:25 and the do_rootfs task clean IMGDEPLOYDIR every time it's run: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n250 Oct 21 13:18:25 my pleasure, I didn't know as well, just where to look :) Oct 21 13:18:43 guess I should do some reading on sstate :D Oct 21 13:20:03 bisbarn: IIRC, there'll be a talk on it next week at Yocto dev days, hopefully the slides and talk will be available later Oct 21 13:20:20 thanks for the info! Oct 21 13:20:40 If you find something interesting on sstate-cache, let me know because I told you everything I knew :D Oct 21 13:21:03 and that's a topic I'm really new at Oct 21 13:21:32 will do Oct 21 13:21:40 RP: would it be useful if i split out a chunk of mut that should be safe Oct 21 13:26:50 Hey guys, I'm working on my freetime and now a bit on company time on SPDX identifiers, on the first patches, I only add the SPDX id, but I didn't removed the former header stating the licence, do I also need to remove the old header? Oct 21 13:29:22 nah Oct 21 13:35:08 rburton: Ok, I think I initially asked this question, but speaking with coworker I couldn't explain why we shouldn't erase the header? Oct 21 13:35:52 well typically a comment is more explicit, Copyright (C) Intel 2010-2019 etc etc Oct 21 13:36:03 spdx doesn't encode the ownership, just the license Oct 21 13:36:41 so i guess a license comment can go if you're adding spdx but there should still be some comment, and i'm not sure i'd be bothered to clean up already merged patches Oct 21 13:36:54 the important thing is spdx headers are in Oct 21 13:37:06 Sure ok ! Oct 21 13:51:15 rburton: please Oct 21 14:19:44 I don't know WTF is going on! Oct 21 14:21:19 litb: welcome to my life! Oct 21 14:21:39 the compiler claims that in line build-mingw/tmp/work/core2-64-w64-mingw32/qtbase/5.12.3+gitAUTOINC+b527725766-r0/recipe-sysroot/usr/include/freetype2/freetype/config/ftconfig.h , I try to inclide "bits/wordsize.h" Oct 21 14:22:03 I figured that there's a class "multilib_header.bbclass" that appears to wrap this header and adds macros for the machine's word size, for whatever reason Oct 21 14:23:06 However, I did override that function of that class that does this, by writing in my machine config this: oe_multilib_header_mingw32() { : } Oct 21 14:24:14 and it apparently works! that literal file that the compiler complains about does *not* include that header! in fact there's no header at all within /usr/include/freetype2 that includes the header. Still, I get the compile error Oct 21 14:24:18 what's going on? Oct 21 14:24:43 the error happens during run of qtbase's do_configure, and makes it so that Qt thinks I have no working freetype library Oct 21 14:25:00 qschulz: My issue of packaging source files of out of tree kernel modules, seems to come from the fact that in the bbclass package, the *.ko are not a part of the elf_file dictionary (eg oe.package.is_elf), then the step separating debug files are not run. Oct 21 14:25:04 For the same reason the out of tree kernel module are not stripped. Oct 21 14:29:12 RP: cheers :) Oct 21 14:46:06 hi, I pla nto add mplayer to my project (not fork one but original) does anybody know if recipe exists ? Oct 21 14:47:53 opennandra: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=mplayer Oct 21 14:48:25 yes mpv is fork but I need to add: http://www.mplayerhq.hu/design7/dload.html#source Oct 21 14:50:06 LetoThe2nd, qschulz, thanks for your help -- I just got my own uboot running. Oct 21 14:50:22 ecdhe: \o/ Oct 21 14:56:35 https://www.meltdown.bar/franchise Oct 21 14:56:47 one of the unofficial hangouts Oct 21 14:59:05 Interesting! Even though I did -C do_configure , Qt still kept the build/ ${B} folder around. Oct 21 14:59:28 i had to rm -rf the workdir/build/ folder, and then it did pick up the new sysroot.. apparently qmake caches preprocessing results.. Oct 21 15:00:28 litb: bitbake -c clean {recipe} should work also Oct 21 15:01:18 litb: `bitbake -C configure` is only going to force do_configure to re-run, not (necessarily) clean out any working directories. Oct 21 15:21:23 litb: bug in the qt recipe, configure should cleandirs[B] Oct 21 15:22:06 eg meson.bbclass do_configure[cleandirs] = "${B}" Oct 21 15:22:29 "before running configure, this directory should exist but be empty" Oct 21 15:23:44 * RP notes a "zecke-rocks" easter egg Oct 21 15:25:35 JPEW, I thought I tried that, but I think I instead tried it on the recipe where the header came from. next time I'll use clean Oct 21 15:25:59 * armpit wonders if this is related to the warrior failure: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-graphics?h=zeus&id=3f5c70649a9aaa13ef755ea57576d2bd6d9d2e60 Oct 21 15:26:11 rburton, ah I see Oct 21 15:26:28 armpit: fails too fast to be that - never boots Oct 21 16:08:18 litb: fwiw, assuming qmake does proper out of tree builds, is just a one line fix to the class. Oct 21 16:08:24 and improves life for everyone Oct 21 16:08:28 so patches welcome :) Oct 21 16:08:45 I'll see what I can do Oct 21 16:09:12 currently I need to get the MS shader compiler working, so that Qt can use ANGLE, which is something that translates OpenGL calls to Direct3d on windows Oct 21 16:10:01 New news from stackoverflow: How to set cmake parameter CMAKE_MODULE_PATH in Yocto project recipe? Oct 21 16:10:05 sadly the shader compiler exists only as a windows .exe, so I need to do some trickery using wine-native to execute it Oct 21 16:10:46 I could just use desktop opengl to build Qt, but opengl is said to be in sad state on windows, so angle seems favourable Oct 21 16:40:05 New news from stackoverflow: Porting flask ASK to bare metal Linux Oct 21 16:51:57 if anyone is running fedora and wants to help debug a mysterious autobuilder error then help would be appreciated Oct 21 16:52:20 turn on reproducible builds, build perl, archive the packages, build perl again, diffoscope on the output Oct 21 16:52:27 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13606) Oct 21 16:52:29 Bug 13606: normal, Undecided, ---, paul.eggleton, NEW , perl isn't always reproducible Oct 21 16:52:41 Trying this question one more time before I go to mailing list... I'm upgrading my project from Sumo to Warrior. I use the archiver to create tarballs of the patched sources in DEPLOYDIR/sources. In Warrior, I'm missing some tarballs for packages in IMAGE_INSTALL. One example is bzip2. Any idea why the source tarballs are no longer generated - Oct 21 16:52:41 they were generated in Sumo. Is there any way for me to force them to be generated? Oct 21 16:53:18 mabnhdev: are you sure bzip is being used? maybe it was removed in oe-core for whatever deps you had Oct 21 16:55:00 rburton: the RPM is being generated. It should follow that the archiver should generate the tarball, no? Oct 21 16:57:37 rburton: tmp/deploy/rpm/x86_64/bzip2-1.0.6-r5.x86_64.rpm Oct 21 16:58:07 mabnhdev, I'm not sure but maybe you're asking about having package_tar in PACKAGE_CLASSES ? Oct 21 16:59:12 you can define it in your local.conf Oct 21 17:00:47 mihai: I do have defined in my local.conf in IMAGE_INSTALL. That was sufficient in Sumo. Has something changed for Warrior? Oct 21 17:01:08 and can have both: PACKAGE_CLASSES = 'package_rpm package_tar' Oct 21 17:03:01 mabnhdev, I don't think so, but it has nothing to do with IMAGE_INSTALL Oct 21 17:03:31 in your example above do you want both bzip2-1.0.6-r5.x86_64.rpm and bzip2-1.0.6-r5.x86_64.tar to be generated? Oct 21 17:04:49 mihai: Ah, I see the confusion. I'm not looking for the source package. I want the archiver's tarball. i.e. tmp/deploy/sources/bzip2-1.0.6-r0-patched.tar.gz. Oct 21 17:05:28 OT, but https://github.com/netromdk/vermin is quite handy Oct 21 17:06:05 mihai: Section 7.32.3.1 of Mega Manual. Oct 21 17:06:33 mabnhdev, oh, that Oct 21 17:06:40 I see Oct 21 17:09:54 rburton: I can take a look. Is it happening every time? Oct 21 17:19:51 mabnhdev, try checking do_deploy_archives logs for some package, e.g. bzip2 Oct 21 17:27:47 mihai: It looks like they are all coming from setscene... Oct 21 17:29:31 mihai: However, even the packages for which I do have archiver tarballs came from setscene also. Oct 21 17:30:50 i'm having trouble building an arm 4.14 kernel for a custom bsp. It seems the kernel metadata (yocto-4.14 branch) includes old patches that were eventually included in that series, so those fail to apply. After removing those, do_patch tries to apply patches for a different architecture (mips). I can't imagine that I'm the only one trying to build a 4.14 kernel, so i feel like i must be doing something wrong.... specifically, it looks like the Oct 21 17:30:51 yocto 4.14 kernel metadata was last updated around 4.14.16; many/most of the patches it includes got accepted upstream shortly after that release, so trying to build the latest 4.14 kernel fails in do_patch. shouldn't that repo's branches be trimmed of patches that get upstreamed? Oct 21 17:38:37 hey rburton Oct 21 17:42:14 JPEW: repeatedly enough for RP to think its fedora specific at least Oct 21 17:42:21 K Oct 21 19:09:32 is there a way to disable or otherwise limit glibc-locale? i don't really care about any locale usage on my system. Oct 21 19:19:41 mischief: GLIBC_GENERATE_LOCALES controls what ones are generated, if any Oct 21 19:19:48 IMAGE_LINGUAS then controls which of the generated ones are installed Oct 21 19:40:20 kergoth: thanks! Oct 21 19:40:55 kind of annoying when you pass -j 48 and glibc-locale tries to run 48 parallel processes on my local machine generating locales :-P Oct 21 19:42:29 ha Oct 21 19:42:41 i often set it to just en_US.UTF-8 when in development Oct 21 19:57:51 everyone be sure to congratualte RP for 9 years at the Yocto Project Oct 21 19:58:15 only 9 years since we learned about the Pky build system under a Concrod in Cambridge Oct 21 20:06:14 you wont let that go Oct 21 20:07:11 Crofton|work: so many memories of that... Oct 21 20:44:17 rp yeah Oct 21 21:07:06 hi folks, FYI the OE TSC meeting is now starting over at #oe-tsc, anyone is welcome to join, minutes will be posted later as well Oct 21 22:01:56 Hello, I've got a question about including specific kernel config options for a specific image. How might I go about including a few kernel config options in one specific image? My first thought is to use config fragments, but I'm not sure how to include the config fragment in the kernel recipe's SRC_URI variable if we're building a specific image. Is this task possible? or is there a better approach I should Oct 21 22:01:58 be considering? Oct 21 22:57:40 robbawebba: what about making a custom layer, with a recipe for each of the various fragments--then include the recipes in the definition of each image? Oct 22 00:48:49 ecdhe: Thanks! That sounds like it would work, although I would like to not create a new layer if possible. My team and I have contemplated making separate layers for these images for other reasons, so I'll keep this one in mind if we go that route. Oct 22 00:51:49 ecdhe: just to be clear, I already have a custom layer with multiple images defined, so I would prefer to not maintain multiple layers if possible. **** ENDING LOGGING AT Tue Oct 22 03:00:24 2019