**** BEGIN LOGGING AT Mon Jan 23 03:00:00 2017 Jan 23 08:54:21 binutils-cross_2.27 compilation just failed for me: Jan 23 08:54:21 syslex_wrap.o: In function `yylex': Jan 23 08:54:21 syslex_wrap.c:(.text+0xb32): undefined reference to `yywrap' Jan 23 08:54:21 collect2: error: ld returned 1 exit status Jan 23 08:54:21 Makefile:1370: recipe for target 'sysinfo' failed Jan 23 08:54:30 That's with OE-core master. Jan 23 09:27:12 rburton: morning! Jan 23 09:27:31 rburton: we should talk about branches and merging patches when you have a moment Jan 23 09:28:13 pohly: that it is a little odd as master seems to be building ok :/ Jan 23 09:29:01 RP: my bad - I had locally updated to flex 2.6.3, which indeed is known to be incompatible with binutils (https://github.com/westes/flex/issues/154). Jan 23 09:29:25 pohly: ok, that makes more sense Jan 23 09:29:38 2.6.2 indeed is still save (well, relatively). Jan 23 09:30:46 pohly: its all relative :) Jan 23 09:40:15 RP: great timing, im hitting an issue with the RSS changes. It appears EXTRA_IMAGEDEPENDS for images doesn't get properly fulfilled Jan 23 09:40:57 RP: hey Jan 23 09:43:58 nrossi: in that things don't end up in the image? or the sysroot? or ??? Jan 23 09:44:33 rburton: I ended up picking a subset of mut/mut2 and pulling into -next along with a python3 fix for the ESDK issue. Jan 23 09:44:43 cool Jan 23 09:44:47 rburton: the end result built ok on the new cluster, it has issue son the main one Jan 23 09:44:55 RP: in the sysroot, e.g. qemu-native (if it isn't pulling in from a DEPENDS on the wrapper) Jan 23 09:45:02 rburton: I did pull the kernel stuff, except the libc-headers piece Jan 23 09:45:23 nrossi: specifically which sysroot? Jan 23 09:45:57 RP: the native one for the image recipe Jan 23 09:45:57 nrossi: and probably more to the point, which wrapper :) Jan 23 09:46:54 nrossi: I'm guessing this wrapper is a "target" recipe (i.e. not cross/native?) Jan 23 09:46:59 RP: so image.bbclass has a DEPENDS += "qemuwrapper-cross". This is what is currently causing qemu-native to appear in the sysroot-native for image Jan 23 09:47:58 guess that needs to be the magic variable name instead Jan 23 09:48:01 nrossi: hmm, right. Whilst its says "cross", its not inheriting the class Jan 23 09:48:16 rburton: not necessarily :/ Jan 23 09:49:07 RP: however the problem is that the sysroot is not populated by EXTRA_IMAGEDEPENDS as well. So e.g. qemu-helper-native is missing Jan 23 09:51:11 nrossi: Well, if you look at the code in image.bbclass it does d.appendVarFlag('do_build', 'depends', deps) Jan 23 09:51:23 nrossi: so these things only need to be available by do_build Jan 23 09:52:35 RP: sure, but is that not the default task, e.g. bitbake core-image-minimal? Jan 23 09:53:30 nrossi: right. I think I understand, its because do_build is noexec Jan 23 09:54:02 therefore it never has its prefunc executed and the sysroot is never extended Jan 23 09:54:25 RP: I thought it might be something like that Jan 23 09:54:51 nrossi: a d.delVarFlag('do_build', "noexec") in that python would confirm Jan 23 09:54:58 (in image.bbclass) Jan 23 09:55:30 nrossi: or we could change it to point at do_image_complete, that might be easier Jan 23 09:55:38 RP: i tried changing the setVar to put the deps on do_rootfs and it worked as expected Jan 23 09:55:57 EXTRA_IMAGEDEPENDS[doc] = "A list of recipes to build that do not provide packages for installing into the root filesystem. Use this variable to list recipes that are required to build the final image, but not needed in the root filesystem. Jan 23 09:56:25 That implies we should be building these things before do_image, not at do_build Jan 23 09:56:25 RP: yep, ambigious with regards to native deps being put in the sysroot Jan 23 09:57:28 nrossi: I guess there are two issues here, one EXTRA_IMAGEDEPENDS and the other is qemuwrapper's behaviour :/ Jan 23 09:58:02 RP: im not sure about qemuwrapper, i was only using it to indicate it was what was bringing in the qemu-native into the sysroot Jan 23 09:58:36 nrossi: so you're saying that dependency is working? Jan 23 09:58:52 the trouble is qemu-native is pulled in all over :/ Jan 23 09:59:05 RP: yes Jan 23 09:59:23 nrossi: ok, I misunderstood that bit Jan 23 10:00:04 RP: sorry, can be hard to describe these things succinctly Jan 23 10:00:18 nrossi: its ok, I'm also still waking up, sorry Jan 23 10:02:35 RP: the nightly-arm failure (no busybox-hwclock) looks like a non-deterministic problem, but that's can't be it right ;) Jan 23 10:03:09 rburton: I think its some transient issue, we've seen this before but not for a while Jan 23 10:03:16 rburton: happens when we change busybox Jan 23 10:03:23 rburton: it didn't happen on the other AB Jan 23 10:03:45 hmm, we have quite some number of noexec tasks with dependencies :/ Jan 23 10:05:17 RP: Putting the EXTRA_IMAGEDEPENDS on do_image_complete as you suggested works well for reference Jan 23 10:06:00 nrossi: I'm tempted to go with do_image_complete for now Jan 23 10:06:50 Hi! Stupid question, but I've just started building poky-based images and I'd to add a kernel parameter (quiet). Could anybody tell me where to do that? Jan 23 10:06:59 All docs point to a kickstart file Jan 23 10:08:02 But I've been doing builds with bitbake so I can't find the .wks files Jan 23 10:09:21 BaloneyGeek|work: APPEND+="quiet" in local.conf should work Jan 23 10:11:44 rburton: Nope, it doesn't Jan 23 10:12:11 It didn't rebuild the image and quemu still shows me the full kernel init output Jan 23 10:13:58 the documentation says use APPEND Jan 23 10:14:21 BaloneyGeek|work: you're running the image with runqemu ? Jan 23 10:14:22 maybe it didn't notice it had to rebuild the image - force it with bitbake someimage -C rootfs Jan 23 10:14:39 BaloneyGeek|work: "runqemu" ignores APPEND, which only ends up getting used when building full-disk images. Jan 23 10:14:43 oh yeah runqemu Jan 23 10:15:04 APPEND only tells the bootloader what options to use, but qemu doesnt use one. Jan 23 10:15:37 runqemu has an argument 'bootparams' to pass kernel options Jan 23 10:15:57 BaloneyGeek|work: something like runqemu qemux86 bootparams=quiet Jan 23 10:16:46 Oh, that makes sense Jan 23 10:17:21 Yep, all of that works. Thanks! Jan 23 10:25:10 rburton: so do I merge -next? Jan 23 10:25:21 I merged in your oeqa fix btw, thanks Jan 23 10:26:25 so there's the busybox-hwclock thing Jan 23 10:26:29 one selftest got OOMd Jan 23 10:26:40 mips test mysteriously failed Jan 23 10:27:02 rburton: OOM was alll ubuntu1404 Jan 23 10:27:26 but the new cluster was all green so we've two transient issues to look at Jan 23 10:27:28 yeah go go go! Jan 23 10:27:54 got a build of arm going here to look at the busybox thing quickly Jan 23 10:28:02 maybe it depends on what exactly type of arm is building first Jan 23 10:29:06 going to walk the dogs now i think, the world is understandably rebuilding Jan 23 10:52:51 rburton: looking at the logs, it installed busybox from do_package, then reran the package_write_* tasks. The do_package data it pulled in is corrupt in that /etc/init.d/* is missing Jan 23 10:53:31 * RP looks at systemd Jan 23 10:59:21 Trouble is I can't find a systemd+qemuarm combination that would put this into sstate :/ Jan 23 11:07:57 someone here with device tree knowledgable? I have here a dts file which is including a dtsi file which is including a dtsi file and inside this file theres a UART defined which I want to disable. Is it just enough to remove this entry? Jan 23 11:11:11 HyP3r: You can also use -> status = "disabled"; Jan 23 11:11:41 HyP3r: You don't need to edit the original, you can just overwrite it after the include Jan 23 11:11:56 with status = "disabled"; Jan 23 11:12:27 HyP3r: Yep with something like "&uartnodename { status = "disabled"; }; Jan 23 11:12:42 ernstp: ah ok, so I have to create an patch which is adding this line into the dtsi file? Jan 23 11:14:00 HyP3r: no you can do it in the parent dts file, using the node name reference syntax Jan 23 11:14:28 (or the full path if so desired) Jan 23 11:15:33 nrossi: the problem is that the parent dts file is not in my meta-layer Jan 23 11:16:01 HyP3r: is any of the dts(i) in your layer? Jan 23 11:16:15 The journey begins here: http://git.toradex.com/cgit/meta-toradex-nxp.git/tree/conf/machine/colibri-vf.conf?h=jethro#n14 Jan 23 11:16:20 And this is not in my layer Jan 23 11:16:22 No Jan 23 11:16:53 Well I guess I just patch the kernel for that. No problem :) Jan 23 11:17:35 Hi, is it possible to ask bitbake what are the task that need to be rerun for a recipe ? Jan 23 11:17:55 https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi?h=toradex_vf_4.4#n181 Jan 23 11:18:19 nrossi: is this the correct position to disable the uart? https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi?h=toradex_vf_4.4#n181 Jan 23 11:18:40 HyP3r: Yep that would be the most straight forward way to modify you the device tree. Looks like you found the line to change :), change "okay" to "disabled" and you will have the change you need :) Jan 23 11:19:01 nrossi: okay thanks Jan 23 11:19:11 geoffrey_l: bitbake -g, will give you a graphviz output for the tasks/packages/etc Jan 23 11:19:28 nrossi: and whats that: https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/vf-colibri.dtsi?h=toradex_vf_4.4#n134 Jan 23 11:19:34 nrossi: Thanks ! :) Jan 23 11:20:22 geoffrey_l: ah sorry, it wont give you the tasks that need to be rerun. Depends what you need to know though Jan 23 11:20:29 my processor has an pin multiplexer, does it make sence to remove here everything correspondening. To make sure that the multiplexer is not affected? Jan 23 11:20:52 HyP3r: Well depends, do you want to remux the pins for a different purpose? Jan 23 11:21:16 no my co processor is using this uart so linux shouldn't touch it Jan 23 11:22:19 rburton: Trouble is I can't tell what went from from this sstate object and I think the builder that created has wiped the tmpdir Jan 23 11:22:50 rburton: I can see the .config from the ptest data and its not right at all Jan 23 11:22:50 HyP3r: Hmmm, you might have to make your co-processor setup the pinmux if linux doesn't set it up for you Jan 23 11:23:03 if the .config isn't right, hwclock disappears Jan 23 11:24:53 nrossi: I search why in a recipe with image-side fetching do_image fail because of do_rootfs who didn't rerun. I also noticed that my base image (without fetching things) as some tasks that rerun each time, so I want to know what they are to search why. Jan 23 11:26:05 geoffrey_l: ah in that case bitbake-diffsigs will help you determine the cause of the rerun Jan 23 11:26:29 nrossi: Thanks, I will try that :) Jan 23 11:27:33 rburton: pretty sure this is the corrupted build: https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1071/steps/Building%20Toolchain%20Images_2/logs/stdio Jan 23 11:27:51 rburton: compile re-ran after being interrupted and killed in a previous build Jan 23 11:28:40 Why do I say that? "WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist" and friends Jan 23 11:38:34 In fact, I can guess how this happens, if you abort the compile, I'd bet it corrupts due to the suid/nosuid thing Jan 23 12:05:50 nrossi: I squashed a fix for the depends issue into the rss commit as I merged it Jan 23 12:07:19 RP: Cool thanks, been testing the RSS on some other builds, works great so far :). Already found a dep issue with pthreads-win32 ;) Jan 23 12:07:40 nrossi: I suspect we're going to find a few dependency issues! Jan 23 12:07:59 nrossi: glad its working though and I appreciate the testing, not many people have done that Jan 23 12:17:44 RP: yes, i've noticed before that busybox fails to rebuild really badly thanks to the suid thing Jan 23 12:18:13 RP: i can dig into this further if you haven't already got far. Jan 23 12:18:42 RP: WARNING: initramfs-live-boot-1.0-r12 do_prepare_recipe_sysroot: Manifest /home/ross/Yocto/poky/build2/tmp/sstate-control/manifest-allarch-linux-yocto.populate_sysroot not found? <— bad? Jan 23 12:19:27 Hi, When I get task hash mismatch error, what are the steps to resolve this, and in which recipe should i modify? "myimage-1.0-r0 do_image: Taskhash mismatch" Jan 23 12:22:03 Unier: did you add some metadata to myimage? Jan 23 12:22:23 rburton: I have a patch! Jan 23 12:22:25 ernstp: Yes there are other packages that I have added Jan 23 12:23:04 ernstp: Is it often metadata added to the image that causes this? Jan 23 12:24:12 Unier: yes, like DATETIME and other variables that change every run Jan 23 12:26:21 rburton: patch sent out and in -next Jan 23 12:27:12 rburton: I've pushed a few things, could you rebase mut/mut2 and see where we are? Jan 23 12:27:26 cool, good fix Jan 23 12:27:30 rburton: I suspect the rest of mut2 is toxic in some form Jan 23 12:27:40 ernstp: I do not think I have DATETIME set, I change only image features, and packages that are installed on the image Jan 23 12:27:44 RP: mut2 is 1/3rd reverts right now :) Jan 23 12:27:48 Unier: there's something called vardepsexclude that helps sometimes Jan 23 12:27:59 rburton: I pulled the kernel updates apart from the headers Jan 23 12:28:07 rburton: I think that should be safe Jan 23 12:28:13 speaking of which Jan 23 12:28:42 Unier: oh, I only got it when I changed my image_type.bbclass to do new fancy stuff. so the _cause_ was very obvious Jan 23 12:29:12 jku: so the musl guys are navel gazing, can you write a patch for connman to inject that magic UAPI define into CFLAGS on musl? A CFLAGS_append_libc-musl should be sufficient. Jan 23 12:29:15 Unier: well undo your changes until it works again :-) Jan 23 12:29:27 ernstp: I have tried PR[vardepsxeclude]="DATETIME" with no success Jan 23 12:29:47 ernstp: Problem is that I only get the error when I run the image build from jenkins, not when I run it manually Jan 23 12:29:53 Unier: I didn't mean you should do that exactly, more an example... Jan 23 12:30:18 Unier: oh, environment variable name collision :-) Jan 23 12:30:35 ernstp: Yeah, i suspect something like that indeed Jan 23 12:30:39 BUILD_ID? Jan 23 12:30:45 ill check Jan 23 12:33:01 the Taskhash mismatch is a pretty horrible part of bitbake... :-) Jan 23 12:33:42 ernstp: I agree :( Jan 23 12:34:30 had to do this little dance to get custom image names: Jan 23 12:34:30 would be amazing if it would explode the hashes to tell you *what* changed Jan 23 12:34:42 IMAGE_NAME_VERSION ??= "${DATETIME}" Jan 23 12:34:42 IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${IMAGE_NAME_VERSION}" Jan 23 12:34:42 IMAGE_NAME[vardepsexclude] = "IMAGE_NAME_VERSION" Jan 23 12:36:13 rburton: the trouble is that it doesn't have the original thing to compare against Jan 23 12:36:13 RP: there's a few bits left in mut which are not toxic (they're only there still as i need to send mails). attr, xserver, container tests for example, all need a run on the AB. Jan 23 12:36:18 rburton: yes please :-) Jan 23 12:36:27 ernstp: patches welcome ;) Jan 23 12:37:10 rburton: the container tests failed on the AB test run Jan 23 12:37:39 bitbake is technically OE and not Yocto? but you're all one big family I assume :-) Jan 23 12:37:53 rburton: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/159/steps/Running%20oe-selftest/logs/stdio Jan 23 12:38:13 rburton: Is someone working on fixing ed btw? Jan 23 12:38:44 ernstp: bitbake is looked after by the same people Jan 23 12:40:12 rburton: mut is still revert crazy :/ Jan 23 12:40:25 RP: ed is surprisingly non-trivial, need to grab lzip from meta-oe to fetch new sources. for M2, i might just submit a src_uri change to point at our mirror. Jan 23 12:40:38 yes, i need to write a few emails, and the reverts in mut2 were a reminder Jan 23 12:41:21 rburton: ok, fair enough Jan 23 12:42:37 btw, can we switch tremor to a tarball rather than svn? Jan 23 12:42:46 Its the only remaining reason we build subversion-native Jan 23 12:43:31 +1 Jan 23 12:44:07 last i looked the tarball was *very* old Jan 23 12:44:15 a better question is "why do we still build tremor" Jan 23 12:44:40 rburton: I'd just like to create a tarball of that revision and stuff it on our mirror Jan 23 12:45:15 rburton: how bad is so-version going backwards (not conflicting with any previous version AFAICT though)? I'll file an upstream bug but not sure about upgrading to that version in oe-core... Jan 23 12:46:15 RP: we don't build tremor in oe-core. i say, move tremor to meta-multimedia Jan 23 12:46:37 oh balls, we do Jan 23 12:46:41 i just can't read Jan 23 12:47:59 jku: what's the context? Jan 23 12:48:56 RP: tremor hasn't been touched for two years now. modern hardware doesn't need non-floating-point decoding. i propose to move tremor to meta-multimedia, disable in oe-core. Jan 23 12:49:14 rburton: https://git.gnome.org/browse/gdk-pixbuf/commit/configure.ac?id=9e87fc089b90a52fd1c2a26769c94dcd843f6a29 -- I think they wanted to bump age with all the previous micro_versions, but it doesn't work like that retroactively Jan 23 12:50:15 so the previous so version 0.3602.0 and that one becomes 0.3600.3 I think Jan 23 12:50:57 urgh i hate libtool versioning Jan 23 12:51:10 yes most confusing Jan 23 12:51:37 looking at https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html, i presume they use major as current and minor as revision? Jan 23 12:52:18 i'd hold off the upgrade before talking to mathias, definitely Jan 23 12:52:34 yeah sounds good Jan 23 12:54:54 rburton: m4_define([lt_current], [m4_eval(100 * gdk_pixbuf_minor_version + gdk_pixbuf_micro_version - gdk_pixbuf_interface_age)]) Jan 23 12:55:32 and revision is interface_age Jan 23 12:55:36 rburton: I have a patch to do something with tremor Jan 23 12:58:21 rburton: If someone else has time to remove it fine, I'm sick of waiting on subversion native though ;-) Jan 23 12:58:31 RP: have a patch to do that :) Jan 23 12:59:39 RP: well i have a patch to disable it so you'll only need svn-native for world builds, and will submit the addition to meta-multimedia shortly so when that is in we can remove it from core. Jan 23 13:02:11 rburton: ok, just base it on top of mine. Tempted to backport mine to morty ;-) Jan 23 13:03:02 RP: yeah might be sensible Jan 23 13:06:04 huh, util-linux's ptest code is mental Jan 23 13:30:28 nrossi: according to the manual http://developer.toradex.com/knowledge-base/freertos-on-the-cortex-m4-of-a-colibri-vf61#Running_a_Firmware_on_CortexM4 I should patch the device tree to make sure that the linux is not touching the uart_b. I have done that, as I told you before. But now I have to change the defargs how the bootloader call linux. Jan 23 13:30:37 nrossi: where I can find this inside my bitbake enviroment? Jan 23 13:30:43 "setenv defargs 'clk_ignore_unused initcall_blacklist=sram_init'" Jan 23 13:31:54 HyP3r: That's a u-boot command no? you will likely need to run that in your U-Boot console and save your environment. Or patch U-Boot's default environment for your target? Jan 23 13:36:13 I want to patch the U-Boots default enviroment so I don't have to run this command Jan 23 13:36:44 This links shows only an example how to do that, if you don't want to change something inside openembedded Jan 23 13:37:36 nrossi: Jan 23 13:38:36 HyP3r: You will have to create a patch for U-Boot, and then put it in a bbappend in your layer. Jan 23 13:41:24 HyP3r: Or you can use 'devtool modify', it might be the workflow you are after Jan 23 13:44:02 nrossi: ok I'll search Jan 23 13:44:42 HyP3r: There is documentation of devtool here: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow Jan 23 14:05:29 nrossi: well okay. I have to take a look into the sources. *sigh* Jan 23 14:05:51 nrossi: but what is devtool. Is that a new tool. In my book I read wasn't this tool mentioned. Jan 23 14:05:57 *books Jan 23 14:06:56 HyP3r: books? devtool has been around for a few releases of OE/Yocto now, it just automates some of the layer/recipe/metadata creation/modification Jan 23 14:09:14 nrossi: https://www.yoctoproject.org/blogs/jefro/2016/yocto-project-books Jan 23 14:09:28 I read https://www.packtpub.com/application-development/embedded-linux-development-yocto-project and https://www.packtpub.com/virtualization-and-cloud/embedded-linux-projects-using-yocto-project-cookbook Jan 23 14:10:53 HyP3r: those books were probably written before devtool was really available Jan 23 14:15:21 nrossi: ok. Is there a way to list which packages/recpies are compilated and generated when I call the image recpie? Jan 23 14:15:33 nrossi: I don't find the uboot recpie Jan 23 14:19:41 HyP3r: depends how u-boot is built into your image, so it won't be in the manifest. Just having a quick look at the machine you are building, it should build "u-boot-nand.imx" into the deploy directory? Jan 23 14:20:27 yeah. Its here Jan 23 14:20:34 HyP3r: The u-boot recipe for your machine is a fork called "u-boot-toradex", that is the name of the u-boot recipe thats built Jan 23 14:21:06 nrossi: I allready searched for this image and found 3 versions of this *.bb file. I have found the fitting image for vfxxx Jan 23 14:21:18 nrossi: bitbake -g -u foobar is also really helpful Jan 23 14:21:21 :) Jan 23 14:23:53 HyP3r: u-boot-toradex_v2015.04 is the one being modified setup to be compatible in the -nxp layer Jan 23 14:24:56 I guess its the meta-fsl-arm-extra u-boot-toradex_2015.04.bb Jan 23 14:28:44 HyP3r: bitbake -s, will tell you the exact version being used. I'm just guessing ;) Jan 23 14:30:35 nrossi: what about this line? should I patch this position? https://git.toradex.com/cgit/u-boot-toradex.git/tree/include/configs/colibri_vf.h?h=2015.04-toradex#n195 Jan 23 14:31:29 this akward zero termination looks like a lot of fun which user can have Jan 23 14:33:27 Are there any other patches people really want to see in M2? Jan 23 14:36:03 marquiz: the perf testing machines don't seem to like your changes :( Jan 23 14:36:13 marquiz: ImportError: No module named 'git' Jan 23 14:40:57 One basic query, if I have PACKAGECONFIG[faad] = "--enable-faad,--disable-faad,faad2" in gstreamer1.0-plugins-bad.inc it means faad plugin won't build ? Jan 23 14:41:13 HyP3r: That looks like the line Jan 23 14:41:17 Ramose: depends on the value of PACKAGECONFIG Jan 23 14:41:43 Ramose: that line defines the 'faad' option, the value of PACKAGECONFIG decides if its enabled or not Jan 23 14:41:52 (the documentaiton has a nice chapter about this) Jan 23 14:42:32 rburton:ok , under this variable PACKAGECONFIG ??= " \? Jan 23 14:42:39 yes Jan 23 14:43:58 rburtin: Its defined like https://paste.ubuntu.com/23852201/ Jan 23 14:44:13 * sgw_ thanks halstead very much for de-spamming mailman! Jan 23 14:44:31 sorry *rburton: it means faad won't build ? Jan 23 14:45:01 Ramose: correst: faad isn't in the list, so faad is disabled. Jan 23 14:46:11 rburton: ok, Let me enable it and see if its build or not Jan 23 14:46:39 rburton; Yes, its compiling , Thanks :) Jan 23 14:50:58 RP: argh, yes, oeqa/utils/metadata requires python-git Jan 23 14:51:50 marquiz: I've kind of been hoping I'd get some performance numbers from somewhere for rss, but nothing yet :( Jan 23 14:51:54 i was asking about this when the dep was introduced :) Jan 23 14:52:45 RP: i might be able to install git there Jan 23 14:52:51 python git Jan 23 14:53:36 (i'd like to ditch that dependency, though) Jan 23 14:53:54 Is there any way to skip do_rmwork for a specific task ? Jan 23 14:54:14 nrossi: or is it better to change this line https://git.toradex.com/cgit/u-boot-toradex.git/tree/configs/colibri_vf_defconfig?h=2015.04-toradex Jan 23 14:54:39 nrossi: I have never changed code inside the uboot. I don't know the structure Jan 23 14:57:02 HyP3r: Not sure if you can set the variable you are after via defconfig Jan 23 14:58:52 geoffrey_l: do_rmwork is a task, if you mean recipe. RM_WORK_EXCLUDE Jan 23 14:59:35 fray: rpm packages generally require /bin/sh, but in case of building the SDK that file is not present in the destination (core-image-.../sdk/image/) Jan 23 14:59:46 fray: how is the check for that overridden? Jan 23 15:03:26 nrossi: I mean task, I created a task that write in ${IMAGE_ROOTFS} and when i redo "bitbake myrecipe" do_image doesn't have some files (exept if I add do_rootfs[nostamp] = "1"). I don't know how do_rmwork actually work but I think it may be related to the files being deleted. Jan 23 15:06:33 I'm having a problem with useradd_base.bbclass, in both the do_configure and do_clean tasks of a recipe of mine which adds two users to the same group, useradd_base tries to delete the group but fails with "groupdel: cannot remove the primary group of user 'webserv'" Jan 23 15:06:47 RP: fixed, next result report should be ok Jan 23 15:07:01 RP: i'll dig the data for the failed buid Jan 23 15:07:13 before trying to delete the group it deletes the first user in that group, but the group deletion itself fails because of the second group user Jan 23 15:07:28 I've googled and found found this discussion: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg79641.html Jan 23 15:07:38 has that been fixed? Jan 23 15:08:08 marquiz: cool, thanks Jan 23 15:08:51 pohly: I did finally look into the parsing=True business and I'm pretty sure it should be in there and comparitively safe to do. bitbake-selftest passes at least Jan 23 15:09:07 RP: you're the expert ;-} Jan 23 15:14:06 maybe I should just add a check in useradd_base.bbclass' function perform_groupdel() if there are other users in the group don't delete it? Jan 23 15:29:15 Should libgcc_s.so.1 (packaged in libgcc) be pulled into images automatically? I just had tcsd (from the trousers package) fail with: "libgcc_s.so.1 must be installed for pthread_cancel to work". Jan 23 15:29:21 And indeed, it's not in my rootfs. Jan 23 15:35:34 RP: given that path replacement always happens in constructed sysroots, i wonder if we could ditch the altered prefix in native.bbclass. Jan 23 15:35:39 s/always/now always/ Jan 23 15:43:18 kergoth: I strongly suspect not as we still install to "/" Jan 23 15:43:36 kergoth: there are two parts to that trick and installing to "/" saves us *tons* of pain Jan 23 15:44:12 pohly: you have to RDEPEND on it from the software :( Jan 23 15:44:26 pohly: there is no dynamic linker markup Jan 23 15:44:27 hmm, good point. changing that would be a compat issue for existing sstates, given that Jan 23 15:44:29 oh well Jan 23 15:44:58 RP: why is glibc not having an RDPENDS for it? There is one in glibc.inc (checking some other glibc feature), but it is commented out. Jan 23 15:45:21 kergoth: Its not compatibility and more that if you don't install to "/" you have to do all the horrible hacks the do_stage () functions used to do :( Jan 23 15:45:45 kergoth: their runtime location needs to be the same as their install location Jan 23 15:46:12 pohly: because glibc doesn't need it and you only need it if you use very specific pthread API Jan 23 15:46:31 pohly: People have complained about this before :/ (being included unconditionally) Jan 23 15:47:54 RP: leaving it to apps to RDEPENDS on libgcc looks like the wrong solution to me. trousers might not even be compiled against glibc which needs libgcc, so why should it RDEPEND on libgcc? That's an implementation detail of glibc, and thus needs to be handled by glibc. Jan 23 15:48:33 But I can also see how someone might want to avoid the overhead if pthread_cancel isn't used. Jan 23 15:49:01 pohly: what we really need is a list of pthread using functions, then the shlibs code would spot references and add the depends Jan 23 15:49:18 RP: agreed. Jan 23 15:49:19 er, libgcc using pthread functions Jan 23 15:55:43 RP: I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=10954 for this Jan 23 15:55:44 Bug 10954: enhancement, Undecided, ---, paul.eggleton, NEW , dynamically detect dependency on libgcc Jan 23 16:00:05 pohly: thanks, redirected to rburton Jan 23 16:07:27 RP: oh, last minute patch to change ed SRC_URI? Jan 23 16:30:04 rburton: I'll take it Jan 23 16:30:47 on the list Jan 23 16:40:08 rburton: is there a bug to solve the ed issue properly? Jan 23 16:40:22 rburton: the patch hides the issue under the carpet, so some other reminder is needed Jan 23 16:41:22 thre is now Jan 23 16:41:24 10955 Jan 23 16:43:06 rburton: I need ideas for this issue: Jan 23 16:43:07 Problem 1: package nativesdk-packagegroup-sdk-host-1.0-r12.x86_64_nativesdk requires nativesdk-wayland, but none of the providers can be installed Jan 23 16:43:07 - conflicting requests Jan 23 16:43:07 - nothing provides /bin/sh needed by nativesdk-wayland-1.12.0-r0.x86_64_nativesdk Jan 23 16:43:21 huh Jan 23 16:43:25 in rpm5 world, we teach rpm5 to ignore that dependency Jan 23 16:43:50 yeah thats basically an assumed host dependency isn't it Jan 23 16:45:13 rburton: it's not a host dependency, it's an SDK image dependency - rpm expects that something will install /bin/sh into /home/ak/development/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk/image/, and cannot find a package that does Jan 23 16:45:44 rburton: because all packages install into that + /opt/poky/2.2/sysroots Jan 23 16:49:02 rburton: much of this code was written by a certain Laurentiu Palcu, and I have a hunch he's not around anymore Jan 23 16:51:33 Does anyone know where bitbake recipes get ${CC} from? Jan 23 16:51:56 Like if I'm building for qemuarm64, where is bitbake finding a aarch64 compiler? Jan 23 16:52:00 meta/conf/bitbake.conf, like nearly every other variable Jan 23 16:53:19 @kergoth - thanks Jan 23 16:53:27 np Jan 23 16:53:30 reading it should be informative Jan 23 16:53:32 ythl: bitbake -e Jan 23 16:53:43 yeah, that too, bitbake -e tells you where each var was defined Jan 23 16:58:39 paulg/paulg_: Which revision of master is that failure? Jan 23 16:59:40 4aa6644f9297 kernel-fitimage: Use compressed ramdisks in FIT images if available Jan 23 17:00:16 paulg: congratulations on finding the first post rss merge bug ;-) Jan 23 17:00:24 :) Jan 23 17:00:35 * fray is looking, there might be a utility called 'patchelf' can can reside the rpath Jan 23 17:00:38 (not sure yet) Jan 23 17:01:25 kanavin: i'll admit that you're now a better rpm/packaging expert that i am right now Jan 23 17:01:36 fray: I know what has happened here Jan 23 17:04:47 kanavin: We need a way to say "ignore this list of dependencies" Jan 23 17:04:57 kanavin: that is inevitable with the sdk Jan 23 17:05:48 ya.. this patchelf can expland the rpath.. which is neat.. however, it seems to verify that the rpath you select is 'correct' before setting it, which won't really work for many of our cases.. Jan 23 17:06:27 fray: adding patchelf as a distro dependency turned out to be a pain, chrpath was the only one we could find in most distros easily Jan 23 17:06:33 instead of rewriting the rpath (or runpath), it zero's the exiting one, grows the dynamic section, and moves the table to the end of the section -- allowing it to be as long as needed.. Jan 23 17:06:52 fray: the bigger problem is that these paths its trying to rewrite are wrong Jan 23 17:06:59 couldn't we just build it ourselves (looks small enough in this case) Jan 23 17:07:12 (I've not checke don dependencies though, if it depends on other things, that falls apart quickly) Jan 23 17:07:20 fray: how do you relocate the patchelf native dependencies? Jan 23 17:07:29 fray: we did try Jan 23 17:07:41 build it static Jan 23 17:07:51 (again, assuming no dependencies on other things) Jan 23 17:09:01 actually wouldn't have to be static.. since it's a -native it would build with the host's libc wouldn't it? Jan 23 17:09:24 and if it's self contained (otherwise) then all it needs is a working ld.so and host libc.. eliminaing the need for the rpath Jan 23 17:10:14 @krogoth, I found where the variable is defined in meta/conf/bitbake.conf, but after I unroll all the macros, it seems like a non-existant compiler Jan 23 17:10:47 so ya, it's a possibility.. but it is C++, so it may require the libcxx library.. Jan 23 17:11:19 something to look into, otherwise someone needs to convince debian folks to fix rpath to not just re-write but to maniuplate the ELF object in a similar way (doesn't look all that hard) and then get people to upgrade Jan 23 17:11:21 :/ Jan 23 17:11:24 paulg: with your failed build, could you confirm that a bitbake X(that failed) -c clean; bitbake X works ? Jan 23 17:11:40 fray: I think this is an existing builddir reuse problem Jan 23 17:11:50 should I copy anything aside 1st? Jan 23 17:11:58 oh Jan 23 17:12:01 much better then Jan 23 17:12:10 paulg: you could save WORKDIR for that recipe I guess Jan 23 17:12:35 paulg, fray: taking a build dir from before rss and then building in it post rss is probably how this breaks. If you have a clean tmp, its probably fine Jan 23 17:13:24 * paulg tries to avoid the nuke and pave unless required. Jan 23 17:14:55 paulg: understandable, and I had thought the system had changed so much, it couldn't possibly reuse anything Jan 23 17:15:37 it did start pretty low in the build ; about 1k of 7k steps. Jan 23 17:17:58 ok, as expected, a -c clean fixed openssl-native Jan 23 17:22:20 paulg: and I was able to reproduce your problem by "bitbake pseudo-native" pre rss, update post rss "bitbake pseudo-native" Jan 23 17:22:44 fray: ^^^ Jan 23 17:22:57 so we now know that a clean tmpdir helps with rss Jan 23 17:23:01 is it just native items that are broken pre/post rss? Jan 23 17:23:14 fray: we don't chrpath for target Jan 23 17:23:44 we may as well just wipe tmpdir at this point though Jan 23 17:23:52 that's what I thought.. same for nativesdk right? so just native should be clearable.. Jan 23 17:24:06 is there any way you can put a marker in the code that causes all of the natives to invalidate? Jan 23 17:24:15 fray: its all going to rebuild anyway so we may as well clean tmp Jan 23 17:24:38 but will the native rebuilds also rebuild all of the target/sdk software? Jan 23 17:24:48 fray: the natives do invalidate, I just bet that something doesn't clean properly (B != S support missing) Jan 23 17:24:55 ah Jan 23 17:25:02 fray: rss means the world totally changes Jan 23 17:26:08 ok Jan 23 17:28:56 paulg: so the answer is to have a fresh tmpdir. I'm torn on whether we bump the tmpdir versioning for this Jan 23 17:29:40 I guess we should at the risk of annying anyone who already upgraded Jan 23 17:29:45 I've still got that same build dir runnnig. Odd that just those two pkgs barfed. Jan 23 17:30:00 paulg: bad "make clean" support Jan 23 17:31:12 paulg: I suspect we pass in new configure options and it doesn't rebuild the binaries Jan 23 17:31:14 rburton: did you try to merge http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131174.html ? Any problems with it? Jan 23 17:32:13 rburton: i was hoping it will be merged before rss patch as rebasing would be easier. Jan 23 17:32:36 ed2: well, the rss patches are in :/ Jan 23 17:32:49 RP: i've noticed :( Jan 23 17:33:17 still churning along ; about 3k of 8k done. Jan 23 17:33:51 paulg: it is quite surprising its only those two Jan 23 17:34:06 paulg: tempting just to bump PR on those two and call it good Jan 23 17:35:09 RP: i'd say absolutely throw in a tmpdir abi bump here Jan 23 17:35:12 heh, jinxed myself. Jan 23 17:35:14 ed2: I can give rebasing it a try if you want. I hadn't realised that patchset was pending. Has it brrn run through the AB ? Jan 23 17:35:16 | ../subversion-1.9.5/subversion/libsvn_ra_serf/blame.c:25:18: fatal error: serf.h: No such file or directory Jan 23 17:35:16 | compilation terminated. Jan 23 17:35:16 | Makefile:761: recipe for target 'subversion/libsvn_ra_serf/blame.lo' failed Jan 23 17:35:30 that looks like a missing dependency and not RPATH Jan 23 17:35:39 paulg: lets say I'm not surprised at all at subversion Jan 23 17:36:00 paulg: we'll be passing in a new path and it won't have changed its config files Jan 23 17:44:38 paulg: did it get much further? Jan 23 17:44:56 paulg: the problem may be in apr-utils-native btw Jan 23 17:45:33 or serf-native :/ Jan 23 17:48:46 still waiting on running tasks to finish Jan 23 17:48:50 Goodday, My build keeps breaking on make for linux-yocto " No rule to make target 'zImage'. Stop." I did a bitbake -e | grep KERNEL_IMAGETYPE and its not being set anywhere is this why that happens? Jan 23 17:54:24 Strike5150: which MACHINE are you building? Jan 23 17:54:39 WARNING: No recipes available for: Jan 23 17:54:40 /home/paul/poky/meta-security/recipes-devtools/qemu/qemu_2.7.0.bbappend Jan 23 17:54:48 RP: Trying to make a new machine based on core2-32 Jan 23 17:54:54 guess qemu got uprev'd Jan 23 17:54:57 RP: I'm not doing very well :*( Jan 23 17:55:43 I will post my machine file and the corresonding bbappend for kernel Jan 23 17:56:40 RP: Machine.conf https://gist.github.com/strike5150/c233d897e4db2cc2c93d6f1c3a02cc0f Jan 23 17:57:22 RP: linux-yocto.bbappend https://gist.github.com/strike5150/88ac9d31f67c2b27071185b7bbb7143c Jan 23 17:58:35 RP: Might be a bit misleading I've commented a few things tried out different iterations in the machine.conf all resulting in the same thing Jan 23 17:59:08 paulg: correct Jan 23 18:00:46 Strike5150: genericx86 isn't a tune so DEFAULTTUNE looks wrong Jan 23 18:01:44 RP: i'll rebase it, no prob. I don't know if it was tested. I thought I missed something, that's why I asked rburton if he tried to merge it. Jan 23 18:01:52 Strike5150: your basic idea looks right at least Jan 23 18:01:53 RP: I've tried with core2-32, I'll run the build again and take it out. Jan 23 18:02:12 RP: Nothing obvious I've missed? Jan 23 18:02:40 Strike5150: been a while since I played with kernels :/ Jan 23 18:03:23 Strike5150: I have to step afk now, sorry, hopefully someone else can spot it Jan 23 18:03:31 RP: Ok thanks Jan 23 18:09:26 subversion is now ok after I cleansstate it and serf-native; we'll see what blows up next Jan 23 18:21:38 ak@kanavin-desktop:~/development$ ./a.out Jan 23 18:21:39 Segmentation fault (core dumped) Jan 23 18:21:39 ak@kanavin-desktop:~/development$ coredumpctl Jan 23 18:21:39 No coredumps found. Jan 23 18:21:45 systemd, I love you! Jan 23 18:22:00 can anyone help? :) where is the core? Jan 23 18:25:03 nevermind, sudo coredumpctl did the trick, but why on earth :-/ Jan 23 18:58:52 I had a reference to /sources/meta-qt in my bblayers then removed it. Another meta layer has a bbappend to qtbase, which is no longer included, generating an error. How can I remove the processing of this recipe now that qt is not included? Jan 23 18:59:47 kanavin: I think it's in journald, and the required permission essentially gives you access to core dumps of all users Jan 23 19:01:29 I should mention I am getting the error when running 'bitbake-layers show-recipes' Jan 23 19:02:22 Just learning yocto, trying to understand the structure and make minor tweaks to an existing build Jan 23 19:04:03 RP: hey, heard you were looking for me Jan 23 19:18:17 Any meta-selinux people here? Something pushed this month seems to have broken setting selinux labels in the build for me. Just curious if anyone else has run into problems. bisecting but it's going to take quite a while. Jan 23 19:33:48 a more focused version of my question: We must use this layer https://github.com/embeddedarm/meta-ts for our board. recipes-qt/qt5/qtbase_%.bbappend requires qtbase.bb from meta-qt layer. the meta-qt layer was removed from bblayers. I get a recipe parse error when I try and run bitbake. What is the correct way to 'remove' processing of this bbappend without modifying the git repo meta-ts? Jan 23 19:55:42 mcudev: the neat way is for the layer doing the appending to see what layers are active before enabling its own parts, so the append is only scanned if meta-qt is present. that needs to happen in meta-ts though. Jan 23 19:56:02 i believe theres a variable to make nonexisting bbappends a warning instead of fatal though Jan 23 19:56:24 set BB_DANGLINGAPPENDS_WARNONLY = 1 in local.conf? Jan 23 19:56:39 bblayers.conf Jan 23 19:56:43 local.conf would be too late Jan 23 19:57:09 wait, no, that should work too Jan 23 19:57:12 clearly i need more coffee Jan 23 20:10:38 joshuagl: are you around? Jan 23 20:12:11 kergoth: todays hack is a tiny class to add a pdb() function, call it in any bit of python and bitbake will stop and wait for you to connect over tcp to a pdb it spawned Jan 23 20:12:29 kergoth: (can't take any credit apart from the five lines to glue rpdb in though) Jan 23 20:12:45 (Pdb) print(d) Jan 23 20:12:45 Jan 23 20:12:46 \o/ Jan 23 20:13:09 nice Jan 23 20:13:34 i've manually added the line in bitbake to inspect memory usage at particular points in the past Jan 23 21:03:51 kergoth: thanks, will try adding that Jan 23 21:30:57 is there a way to provide authentication to SRC_URI fetching from https://, without encoding the username/password in the recipe? we want to pull some vendored binaries but do not want to check the credentials into git Jan 23 21:31:16 with recent wget, you can use a wget askpass helper Jan 23 21:31:18 otherwise .netrc Jan 23 21:32:29 .netrc works for me Jan 23 21:32:34 @kergoth thanks Jan 23 21:32:50 np Jan 23 21:35:59 BB_DANGLINGAPPENDS_WARNONLY = "true" appears to work Jan 23 21:39:09 BB_DANGLINGAPPENDS_WARNONLY if needed means some layer is misbehaving Jan 23 21:39:22 yes it is Jan 23 21:39:26 you should inform the layer which is causing it Jan 23 21:39:51 will do Jan 23 21:40:24 so is it typical for yocto to chew up 35G of hdd space for a build? Jan 23 21:41:28 yes Jan 23 21:41:45 you are building a full platform from scratch Jan 23 21:42:02 it appears that dbg packages are huge compared to the actual package Jan 23 21:42:28 you can change options to not generate debug info if you dont need it Jan 23 21:44:00 i am looking for the option that enables that Jan 23 21:44:31 new to yocto, working with new board with yocto support provided by mfg Jan 23 21:44:56 RP: I am seeing this error with recipe sysroot enabled http://pastebin.com/XH5Vc98b Jan 23 21:45:07 documentation is "do this and don't ask questions", but we need to add packages Jan 23 21:45:18 RP: this package configures correctly on ubunut Jan 23 21:45:33 lamego: kind of, for a short while at least, what's up? Jan 23 21:46:24 khem: not seen that before. Any idea what this "cfg" directory is? Its not any standard path I've heard of before Jan 23 21:46:26 mcudev: look for SELECTED_OPTIMIZATION and remove -g from it Jan 23 21:46:58 RP: I was looking at the first error which is something to do with regexp Jan 23 21:47:16 is the following valid in local.conf: EXTRA_IMAGE_FEATURES -= "dbg-pkgs" Jan 23 21:47:24 khem: that is from recent autotools, lots of recipes do that Jan 23 21:47:35 joshuagl: Hi Joshua. Just to let you know that I closed 10875 & 10876. I couldn't reproduce and couldn't find the issue in logs. Jan 23 21:47:44 khem: fatal part is aclocal: error: couldn't open directory 'cfg': No such file or directory Jan 23 21:47:57 joshuagl: we can reopened if needed of course. Jan 23 21:48:11 *reopen them Jan 23 21:48:15 mcudev: EXTRA_IMAGE_FEATURES_remove = "dbg-pkgs" is Jan 23 21:48:30 thanks Jan 23 21:49:05 RP: AC_CONFIG_HEADERS([cfg/config.h]) and AC_CONFIG_MACRO_DIR([cfg]) AC_CONFIG_AUX_DIR([cfg]) Jan 23 21:49:26 RP: removing dbg-pkgs wont stop compiler from creating debug info Jan 23 21:49:38 so objects still will be large Jan 23 21:49:54 khem: I didn't realise that was the question Jan 23 21:50:31 khem: does the recipe set acpaths? Jan 23 21:50:34 nodejs-4.4.3-r0.cortexa9hf_neon.rpm = 3.3M Jan 23 21:50:42 nodejs-dbg-4.4.3-r0.cortexa9hf_neon.rpm = 94M Jan 23 21:50:46 khem: acpaths = "cfg" might help it Jan 23 21:51:09 and I'm running in a VM on a smaller SSD, so space is starting to become an issue Jan 23 21:51:12 khem: "-I cfg" even Jan 23 21:51:20 so I want to stop the dbg packages Jan 23 21:51:32 khem: Its possible the autotools changes have affected this somehow Jan 23 21:52:13 mcudev: SELECTED_OPTIMIZATION_remove "-g" ? Jan 23 21:57:01 will try Jan 23 21:57:22 RP: I think no it does not set acpaths Jan 23 21:59:55 lamego: no problem Jan 23 22:01:29 thanks for the notice Jan 23 22:03:35 RP: acpaths doesnt help Jan 23 22:07:50 khem: :( Jan 23 22:08:12 khem: not sure why that would suddenly break. Is it a public recipe? Jan 23 22:08:36 RP: https://hastebin.com/iyidaxatok.m Jan 23 22:08:46 autotools.bbclass is overriding my setting Jan 23 22:09:02 RP: yes it is Jan 23 22:09:33 https://github.com/Metrological/meta-metrological/tree/master/recipes-graphics/westeros Jan 23 22:11:58 RP: acpaths_forcevariable = "-I cfg" works Jan 23 22:12:47 RP: https://github.com/openembedded/openembedded-core/blob/master/meta/classes/autotools.bbclass#L30 Jan 23 22:12:48 khem: did you set it after the inherit autotools ? Jan 23 22:12:53 shouldnt this be ?= Jan 23 22:13:00 we should probably make it a weak default Jan 23 22:13:06 khem: snap! Jan 23 22:13:53 is anyone having trouble with glibc-initial on x86 archs? Jan 23 22:14:03 is anyone ELSE* Jan 23 22:14:16 RP: its 12 year old setting I wonder if its set in stone :) Jan 23 22:14:53 aehs29: autobuilder is green... Jan 23 22:14:56 khem: :D Jan 23 22:15:22 aehs29: you have to be specific as in describe your error first so others can relate to it Jan 23 22:15:29 RP: interestin, Im having issues with both genx86 and qemux86, on different machines Jan 23 22:15:34 khem: give me a sec Jan 23 22:16:09 khem: | checking installed Linux kernel header files... missing or too old! Jan 23 22:16:11 | configure: error: GNU libc requires kernel header files from Jan 23 22:16:36 khem: ERROR: Task (/home/aehernan/yocto/poky/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure) failed with exit code '1' Jan 23 22:16:50 khem: it doesnt show up on genx86-64, Ive not tried other archs yet Jan 23 22:16:52 RP: there are recipes in oe-core which override acpaths https://hastebin.com/jutowaqodo.pl Jan 23 22:17:02 RP: I wonder how that code ever worked Jan 23 22:17:40 khem: they set it after inherit autotools ? Jan 23 22:18:50 RP: I am setting it after inheriting autotools Jan 23 22:20:12 khem: you shouldn't need forcevariable then Jan 23 22:22:24 khem: aehs29: I also saw this issue on my machine building for qemux86 Jan 23 22:27:30 RP: yeah order matters Jan 23 22:27:50 I have to only set it after inheriting autotools Jan 23 22:28:29 RP: I think using ?= is still a better option Jan 23 22:28:39 to fix the order dependency Jan 23 22:29:05 khem: agreed Jan 23 22:29:15 khem: its just old code Jan 23 22:29:39 RP: I will sent a patch to fix it Jan 23 22:29:47 khem: sounds good thanks Jan 23 22:29:50 Anyone seen an inability to login over ssh with morty? The server is immedidately killing the connection, saying "debug1: Killing privsep child" with nothing else useful. disabling privsep makes it successfully log in Jan 23 22:30:13 kergoth: no... Jan 23 22:30:38 paulg: did that build work out? Jan 23 22:33:51 kergoth: are you using UsePrivilegeSeparation=sandbox Jan 23 22:33:59 yep Jan 23 22:34:30 RP: hi there. Once patchwork swallows your patchset wrt recipe-sysroot I'll surely need your help for klcc-cross :) Jan 23 22:35:31 ant_home: We've not talked about that in a while! Jan 23 22:35:56 heh, just minor breakages up to now :) Jan 23 22:36:16 ant_home: we might get lucky and it might just work Jan 23 22:37:09 let see, I'm catching up now with the deploy dir changes Jan 23 22:38:30 btw klcc development seems stale Jan 23 22:38:35 so klibc Jan 23 22:38:51 I'll spend my little time with musl in future Jan 23 22:41:03 RP: posted here https://patchwork.openembedded.org/patch/136278/ Jan 23 22:41:35 hi khem Jan 23 22:43:58 khem: queued in -next Jan 23 22:44:47 RP: another problem I am seeign is when building gptfdisk Jan 23 22:45:01 its symlinking native .so into sysroot Jan 23 22:45:28 see https://hastebin.com/ecibawides.pas Jan 23 22:47:02 khem: :( Jan 23 22:47:13 compiler says https://hastebin.com/upeluweteb.vbs Jan 23 22:47:26 khem: we'll just have to deal with each issue in turn. Its why I've merged it now, give us time before release Jan 23 22:47:33 yeah thats fine Jan 23 22:47:46 I am helping :) Jan 23 22:48:19 khem: I appreciate it. That error is odd, why would the arm compiler poke into the native sysroot? :/ Jan 23 22:48:38 RP, a couple other pkgs needed -c cleansstate and now I need to figure out why this new error happens: Jan 23 22:48:43 | configure: error: could not find dbus-binding-tool in $PATH. You can run Jan 23 22:48:43 | ./configure DBUS_BINDING_TOOL=/path/to/dbus-binding-tool to define Jan 23 22:48:43 | a custom location for it. Jan 23 22:48:43 | ERROR: configure failed Jan 23 22:48:43 | ERROR: Function failed: do_configure (log file is located at /home/paul/poky/build/tmp/work/core2-64-overc-linux/xfdesktop/4.12.3-r0/temp/log.do_configure.15578) Jan 23 22:49:01 RP: I am reusing sstate Jan 23 22:49:06 paulg: I think a clean tmp is going to be the way forward Jan 23 22:49:14 I wonder if that plays a role Jan 23 22:49:28 khem: I'd very much any checksums match pre rss Jan 23 22:49:29 yah for sure that would have been faster, but I am stubborn. :) Jan 23 22:49:33 RP: I was wondering if LAYER vesion should be bumped Jan 23 22:49:48 paulg: I think I'll have to bump the tmpdir version number Jan 23 22:50:03 argh..new error of today? Jan 23 22:50:05 ERROR: python3-pygobject-3.22.0-r0 do_prepare_recipe_sysroot: Function failed: extend_recipe_sysroot Jan 23 22:50:36 ant_home: that says what failed but not how... Jan 23 22:50:48 ok, so it isnew... Jan 23 22:51:30 here: http://pastebin.com/7L4f4yr4 Jan 23 22:53:43 deleted sstate now lets see a build from scratch completely Jan 23 22:53:44 ant_home: could you apply this patch: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=aa25ece5bddcbf877d4b90530251a340d914f991 (or change the check_call to check_output) and then rerun please. That error message doesn't help :( Jan 23 22:56:23 yup, rebuiling Jan 23 22:57:15 ant_home: I think I just increased the urgency of merging that one Jan 23 22:57:26 still failing, after -c cleansstate Jan 23 22:57:32 patch applied Jan 23 22:57:54 do you need full log? Jan 23 22:58:41 ant_home: one like the one you pasted above please Jan 23 22:58:52 ant_home: should have the output for the failed command this time Jan 23 22:59:41 RP: http://pastebin.com/6ZYcvt1K Jan 23 23:01:35 ant_home: which version of python 3 is on your system? Jan 23 23:02:30 hi guys, I'm working on an image that uses meta-qt5 with egl plugin for rendering. It was all working but I recently added another layer meta-kontron for some GPIO drivers. Now /usr/lib/dri/kms_swrast_dri.so has disappeared from my image. Any tips on how to debug this? Jan 23 23:02:31 RP: ant_home 3.6 doesnt work well yet with master btw. Jan 23 23:02:49 khem: so I heard :/ Jan 23 23:03:05 RP: I have locked my archlinux to 3.5 for now Jan 23 23:03:21 im gathering that it is somethign to do with the configuration of mesa and perhaps virtual providers whether it would choose to include the kms_swrast library or not Jan 23 23:03:28 seems 2.7.2 default and 3.5 Jan 23 23:03:48 Ubuntu 16.04 vanilla Jan 23 23:04:31 ant_home: I'd hoped python would show the output of the failed command in the traceback but it seems not :( Jan 23 23:04:36 Guest15638: does meta-kontrol have bbappends for mesa Jan 23 23:04:52 andrea@ThinkPad-T520:/oe/oe-core/build$ pyversions -i Jan 23 23:04:53 python2.7 Jan 23 23:05:14 ant_home: its python3 we care about these days (python3 --version) Jan 23 23:05:17 I have to check how Ubuntu does it...I only know Gentoo's way Jan 23 23:05:20 ant_home: could you share /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/temp/log.do_prepare_recipe_sysroot.27568 ? Jan 23 23:06:23 khem: no I"m not seeing any references to mesa in meta-kontron. The new layer has some linux kernel patches that seem fairly harmless, and a new machine file which I switched over to. But the difference between the machine files seems minimal. Jan 23 23:06:52 I think a while ago I was missing kms_swrast_dri.so and I fixed it by adding mesa-megadrivers to my image Jan 23 23:07:01 is it changing DISTRO_FEATURES or MACHINE_FEATURES Jan 23 23:07:06 but mesa-megadrivers is still on the image it just doesn't include that particular library now Jan 23 23:07:09 yes it does Jan 23 23:07:42 its adding va-impl-intel to MACHINE_FEATURES which I think is a graphics thing Jan 23 23:07:46 RP: https://filebin.net/xbykc718u6ahp79l Jan 23 23:07:49 could that have broken mesa dri? Jan 23 23:07:49 do you have opengl in DISTRO_FEATURES Jan 23 23:08:18 could be I dont know much about meta-kontron and it doesnt seem to be open Jan 23 23:08:41 um, is there an easy way to check that from bitbake? I have about 10 layers so not sure whats the easy way to check the DISTRO_FEATURES for my specific image and machine Jan 23 23:09:05 ant_home: that is definitely more helpful, the real error is in there Jan 23 23:09:15 bitbake -e bash | grep -e "^DISTRO_FEATURES=" Jan 23 23:09:27 Guest15638: do that with and without kontrol layer Jan 23 23:11:08 ant_home: does /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/etc exist? Jan 23 23:11:29 yes Jan 23 23:11:55 andrea@ThinkPad-T520:/tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0$ ls Jan 23 23:11:55 0001-configure.ac-add-sysroot-path-to-GI_DATADIR-don-t-se.patch Jan 23 23:11:55 pygobject-3.22.0 Jan 23 23:11:55 recipe-sysroot Jan 23 23:11:55 recipe-sysroot-native Jan 23 23:11:55 temp Jan 23 23:12:26 ant_home: we need to figure out why /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/usr/bin/postinst-ldsoconf-gobject-introspection is failing (its a script) Jan 23 23:12:36 ant_home: you could even try running it by hand Jan 23 23:13:17 RP: has there been a change that would cause Taskhash mismatches when running distro_check (via INHERIT += "distrodata")? Jan 23 23:13:38 sgw_: no one change jumps out Jan 23 23:14:25 RP: ok, I will open a bug then, very reproduicble. Jan 23 23:15:33 RP: http://pastebin.com/9VgiByNX Jan 23 23:15:58 ant_home: are you sure /tmp/build/tmp-glibc/work/armv5e-oe-linux-gnueabi/python3-pygobject/3.22.0-r0/recipe-sysroot/etc/ exists ? Jan 23 23:16:17 no /etc Jan 23 23:17:16 created that and the script runs Jan 23 23:18:18 ant_home: ok, I think there is simply a bug there Jan 23 23:18:55 I've created now the dir and it compiles Jan 23 23:19:25 just fine Jan 23 23:20:49 ant_home: I think this is the right fix: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=20b72a564c4f7cccfa4bbecd8c4778899b0990a5 Jan 23 23:21:00 Cut and paste failure Jan 23 23:21:50 echoing too much... Jan 23 23:24:19 RP: btw as of today/now klcc-cross still compiles and so its artifacts :) Jan 23 23:24:50 khem: no differences in DISTRO_FEATURES Jan 23 23:24:56 ant_home: ! :) Jan 23 23:26:02 somehow kernel disappears from DEPLOYDIR on rebuild from sstate but this is minor problem :p Jan 23 23:26:04 main difference that is relevant to graphics seems to be that meta-kontron has MACHINE_FEATURES_append = " va-impl-intel" Jan 23 23:26:23 and also MACHINE_HWCODECS ?= "va-intel gstreamer-vaapi-1.0" Jan 23 23:26:51 should i try commenting those out, is it feasible that that could have caused kms_swrast_dri.so to be missing from mesa? Jan 23 23:27:00 RP: go forth with the changes! Jan 23 23:27:09 thanks Jan 23 23:27:36 gn Jan 23 23:42:08 * RP fires the M2 build Jan 23 23:42:36 RP: Awesome I will keep an eye on it later Jan 23 23:43:52 hi all, do we know if we can build Morty on RHEL 6.8? I do see that CentOS 6.x was dropped as per documentation Jan 23 23:45:46 bah, still one subversion recipe in OE-Core Jan 23 23:46:17 manju: I suspect there may be some issues, how serious they are I don't remember... Jan 23 23:48:09 RP: ok thanks Jan 23 23:52:08 manju: the kernel version of RHEL 6 is probably the biggest problem. If i remember correctly uninative is built for 3.2+ kernels Jan 23 23:58:52 nrossi: ok, how do we find uninative build versions? Jan 24 00:01:48 manju: what do you mean by build versions? Jan 24 00:02:57 nrossi: sorry I meant, how to identify if uninative is built for 3.2+ kernels? Jan 24 00:03:46 manju: oh, just run file on ld-linux in the uninative tarball Jan 24 00:06:06 manju: actually just file lib/*, seems ld doesn't have the kernel abi tag Jan 24 00:16:02 nrossi: thanks **** ENDING LOGGING AT Tue Jan 24 03:00:01 2017