**** BEGIN LOGGING AT Fri Jan 27 03:00:02 2017 Jan 27 04:29:30 I notice the morty docs don't list python3 in the list of required packages in the quick start guide, is that an oversight? Jan 27 06:09:39 smurray: probably, but python3 is installed on most distros now a days Jan 27 06:20:16 khem: sure. I noticed it with a container setup I'd created with debootstrap, probably not typical. Jan 27 06:21:48 it wont hurt to add it though, feel free to send a patch Jan 27 06:22:36 khem: okay Jan 27 07:36:17 I am trying to figure out how to create an .imx u-boot image using mkimage -T imximage but I cannot find the "right place"(tm) to put the -T imximage argument. Jan 27 08:10:32 bluelightning: "devtool upgrade" fails with an error about reading the non-existent recipe from workspace/recipes. Not sure whether it is related, but in the case that I am currently trying (devtool upgrade --srcrev 922421cf795d53d339862bb2d99f1a85c96ad9a3 --version 0.6.4 multipath-tools) rebasing patches fails. Jan 27 08:10:52 I guess I should file a bug... Jan 27 08:20:50 deva: doesn't IMAGE_BOOTLOADER = "u-boot" and image_type_fsl.bbclass do the right thing? Jan 27 08:30:56 ernstp, I am currently using u-boot-fslc (from meta-fsl)and it Jan 27 08:31:18 form meta-fsl-arm Jan 27 08:32:06 it produces u-boot-mfgtool-v2016.11+gitAUTOINC+615fdbc2b6-r0.img Jan 27 08:33:22 what MACHINE? Jan 27 08:33:54 imx6ulevk Jan 27 08:34:16 ernstp, I cannot find image_type_fsl.bbclass anywhere... do I need another layer? Jan 27 08:35:16 that's wierd... which branch of meta-fsl-arm? Jan 27 08:36:08 ernstp, HEAD as of a few months ago Jan 27 08:36:35 sure it's not there? in classes...? Jan 27 08:37:11 then in conf/machine/include/imx-base.inc there's a bunch of defines like UBOOT_MAKE_TARGET ?= "u-boot.imx" and UBOOT_SUFFIX ?= "imx" Jan 27 08:37:24 I'm not really sure what problem you're trying to solve actually :-) Jan 27 08:38:40 ernstp, Aah... it's called image_type*s*_fsl.bbclass :-) Jan 27 08:41:43 pohly: if you would please, thanks Jan 27 08:42:30 I tried setting UBOOT_SUFFIX = "imx" in my bbappend and now it seem to create the .imx file but fails in a copy step: http://pastebin.com/01xR1N9A Jan 27 08:56:25 ernstp, It appears that the UBOOT_SUFFIX is set to .img in the imx6ulevk machine file in metal-fsl-arm. Setting it in my own machine file makes the "copy to deploy" step look for an imx file, but the mkimage command still uses "-T firmware" and not "-T imximage" Jan 27 09:00:14 bluelightning: See https://bugzilla.yoctoproject.org/show_bug.cgi?id=10981 - I had a quick look through the code, but it did not become clear to me where the file should have been created at that point (if at all) or whether the call itself should create the file, so I'll leave that in your capable hands. Jan 27 09:00:15 Bug 10981: normal, Undecided, ---, paul.eggleton, NEW , devtool: upgrade fails, recipe file not found Jan 27 09:00:43 deva: clean? Jan 27 09:01:17 In the meantime I am doing the recipe upgrade manually. It is a lot more work, which just goes to show how useful devtool is - when it works ;-} Jan 27 09:03:16 ernstp, Would "bitbake -c clean u-boot-fslc" be enough? or should I clean "deeper" Jan 27 09:03:55 deva: looks good :-) Jan 27 09:04:01 RP: I'm looking at cross.bbclass where target_base_libdir is built with "{target_base_prefix}/${baselib}" instead of just immediately expanding ${base_libdir}. This is a problem if I modify base_libdir for usrmerge... Jan 27 09:04:03 ernstp, Same problem Jan 27 09:04:32 RP, I realize dffe253336f was 6 years ago but maybe you have some ideas? Jan 27 09:04:56 It appears that the UBOOT_SUFFIX is not used by the mkimage command. Do you know where I can find it? IO have traced the 'require' tree to u-boot.inc but it is not present in that file Jan 27 09:13:08 ernstp, The oe_mkimage function in meta/classes/image_types_uboot.bbclass does not contain the phrase "-T firmware" but rather "-T ramdisk" so that one is not the one being called. Jan 27 09:15:59 deva: the -T imximage command is in the u-boot source code... Jan 27 09:17:21 ernstp, You mean the recipe? or the c code? Jan 27 09:18:25 eh... byt "c code" I of course mean the code from the u-boot git repo Jan 27 09:27:12 too much recursions while resolving '%s'; loop in '%s'" % Jan 27 09:27:18 Error from package class Jan 27 09:27:29 can anyone help on this ? Jan 27 09:28:58 jku: whatever you do, please please please don't propose immediate expansion. It causes untold problems for the cross classes and we're finally nearly free of it Jan 27 09:31:33 good to know :) Jan 27 09:31:37 jku: looking at that commit, the basic idea is that you can add in multilib overrides and the variables all adjust themselves to the right values Jan 27 09:32:06 jku: if you immediately expand, the makeup of the variable is lost and they don't change Jan 27 09:33:08 thanks, I'll try to figure out a fix Jan 27 09:34:03 jku: with usrmerge doesn't exec_prefix or base_prefix change and then these adjust? Jan 27 09:35:28 base_prefix can't change because e.g. sysconfdir = "${base_prefix}/etc" Jan 27 09:35:53 jku: this sounds rather like a mess :( Jan 27 09:36:31 * RP tries to remember what the big advantage of usrmerge is Jan 27 09:37:34 jku: you probably want target_base_libdir_class-cross = "${target_exec_prefix}/${baselib}" Jan 27 09:44:44 good morning Jan 27 09:45:59 deva: u-boot git Jan 27 10:22:02 ernstp, I figured out that I needed the u-boot-imx-mfgtool package instead. This however failed during compilation due to some gcc6 related issues. I have fixed those by overriding the git src options ot use a more recent version and compilation/imx image generation seem to work. Jan 27 10:22:23 It now fails during deployment step with a "missing SPL" file Jan 27 10:50:03 ernstp, A u-boot-imx-msgtool_%.bbappend file with the following contents: http://pastebin.com/9g8dxSDc fixed the issues. Jan 27 11:25:11 ed2: i thought i had all of your patches but still get fails like https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/1099/steps/BuildImages_1/logs/stdio. can you check ross/mut? Jan 27 11:27:28 anyone building recipe with hg:// in SRC_URI? here it fails with /usr/bin/env: hg: No such file or directory Jan 27 11:28:50 d.appendVarFlag('do_fetch', 'depends', ' mercurial-native:do_populate_sysroot') Jan 27 11:28:54 is there Jan 27 11:51:10 Hi all. Any recommendations on how to do building / minification of web stuff in a yocto build? Most of the tools i know of nowadays use node.js. However there doesn't seem to be a good nodejs-native for yocto (?) Jan 27 11:51:56 Anticom: there is nodejs recipe in meta-oe Jan 27 11:52:26 there is even separate layer with more node.js versions Jan 27 11:53:08 JaMa: Well i need a native package to use it on the build host. I don't want to run nodejs apps on my device Jan 27 11:53:22 and nodejs provides native as well Jan 27 11:53:51 JaMa: which one? the meta-oe one or the meta-nodejs one? Jan 27 11:54:03 probably both Jan 27 11:56:11 since krogoth there should be noteworthy support for node in oe, before that, we have meta-nodejs :-) Jan 27 11:57:10 we're using nodejs in meta-webos since before Dylan was released :) Jan 27 11:58:09 JaMa: yes, already saw a lot of your infrastructure there. yet i'd rather point to the, erm... more 'mainstream' ressources nowadays :) Jan 27 11:58:35 JaMa: having the npm fetches and devtool support for example seems to be really handy. Jan 27 11:58:57 yes, I agree that stuff is much better now and closer to upstream Jan 27 12:00:16 i'll still have to look into building some NaN based module using the new structure, but so far it seems to be promising. Jan 27 12:02:40 LetoThe2nd: sadly we're still on jethro. So i guess going for meta-nodejs? Jan 27 12:04:06 OE @ ~/meta-openembedded $ grep BBCLASS ./meta-oe/recipes-devtools/nodejs/nodejs_0.12.7.bb Jan 27 12:04:09 BBCLASSEXTEND = "native" Jan 27 12:04:10 in jethro Jan 27 12:15:48 RP: do you remember reasons for immediate expansion of STAGING_DIR_HOST in allarch.bbclass and how it relates to current recipe-specific-sysroots? Jan 27 12:16:16 JaMa: it used to have MACHINE in it which was no doubt the reason Jan 27 12:16:37 JaMa: since allarch packages shouldn't depend on MACHINE. What problem are you seeing? Jan 27 12:18:05 I have recipe which sets PV in python function and STAGING_DIR_HOST="....luna-init/1.0-r12/recipe-sysroot" RECIPE_SYSROOT=".....luna-init/2.0.1-13-r12/recipe-sys| Jan 27 12:18:09 root" Jan 27 12:18:46 and because of allarch it's using STAGING_DIR_HOST value to find the dependencies and fail, because of different version directory Jan 27 12:19:00 JaMa: hmm, right :/ Jan 27 12:19:10 JaMa: we can likely remove that from allarch.bbclass now Jan 27 12:19:57 ok, will try that and if it isn't enough I'll create simpler test case for oe-core Jan 27 12:26:45 marquiz: the perf machines broke again and don't show how they failed, any clues what broke in master? Jan 27 12:28:47 hi ... strange question but is there a way I can get a binary build in another package I depend on? Jan 27 12:31:12 so e.g. like the busybox use case there is a busybox package builds the main package and then I build a getty.bb around depend on busybox copy the busybox bin to /opt/getty Jan 27 12:38:25 rburton: can you drop hddimg patchset, please? that should help. Jan 27 12:38:56 rburton: I'll send v3 today Jan 27 12:54:24 RP: uhh, i hadn't checked today's results, yet, let me see... Jan 27 12:58:06 :qa Jan 27 12:58:23 hello Jan 27 12:58:25 sry, wrong window in focus Jan 27 12:58:44 is there any advantage in placing PV and maybe PR in the recipe name? Jan 27 12:59:37 for me it makes it harder to spot content change when also the PV or PR has changed, because instead of a diff, i just see in gerrit that one file was removed and another added Jan 27 13:02:57 RP: http://pastebin.com/K9M5KU8A Jan 27 13:04:45 RP: i really need to fix error reporting of the script so that it will show bitbake output in the backtrace Jan 27 13:04:46 ed2: ok, thanks Jan 27 13:05:15 cornel: pr, definitely not. git can handle rename detection, so gerrit should be able ot. Jan 27 13:07:54 rburton, ok, thank you Jan 27 13:09:04 cornel: if gerrit really can't then feel free to put PV in the recipe for your own stuff. putting it in the filename is just a convenience and idiom from when OE used to contain many of releases of each recipe. Jan 27 13:09:37 rburton, so its mainly there for historical reason, so to speak? Jan 27 13:14:32 cornel: its a historical convention that is helpful to easily show what version a recipe is Jan 27 13:14:50 thank you very much rburton Jan 27 13:19:06 great, selftest is just hanging Jan 27 13:30:59 marquiz: I have no idea why its doing that, nothing else with master is afaik :( Jan 27 13:31:38 marquiz: fixing the script to share that output would help Jan 27 13:32:30 must be related to build perf test re-using artefacts Jan 27 13:32:45 i'm fixing the output problem atm Jan 27 13:33:14 marquiz: which aretfacts? Just sstate right? Jan 27 13:33:27 yes Jan 27 13:33:43 marquiz: it should work but worth exploring... Jan 27 13:33:46 (and downloads and cache) Jan 27 13:33:56 JaMa: I tried removing the expansion in allarch locally and it seems to work Jan 27 13:34:46 marquiz: hm, it breaks after enabling rm_work Jan 27 13:34:48 RP: i guess must be sstate as test1 build core-image-sato without problems Jan 27 13:35:07 esdk test does not use rm_work Jan 27 13:37:43 marquiz: it doesn't but its broken by then! Jan 27 13:39:01 marquiz: are the failures for each step the same? Jan 27 13:39:15 RP: basically yes Jan 27 13:39:55 marquiz: local test didn't reproduce it :/ Jan 27 13:41:07 RP: i'm running locally, too... Jan 27 13:44:34 RP: you're right that rm_work might actually break it Jan 27 13:45:08 because the subsequent tests try to run a preparational build in the same tmpdir Jan 27 13:49:21 marquiz: right, we need to figure out what the reproducer is... Jan 27 13:50:27 Looking at the numbers, it seems I managed to wipe 2GB of the disk usage, which raises questions about where the remaing 4GB comes from with rss Jan 27 13:51:29 RP: 4gb is still quite a bit Jan 27 13:51:47 marquiz: right Jan 27 13:52:58 RP: i could investigate that, but unfortunately not before monday Jan 27 13:53:32 marquiz: right, we're going to have to look into it... Jan 27 13:54:16 marquiz: getting the perf benchmarks working is first priority Jan 27 14:02:12 my NATIVELSBSTRING apparently changed from "Debian-testing" to "Debian-9.0" and all sstate broke. Is this normal? Jan 27 14:03:42 yes Jan 27 14:04:03 sad but true as we can't tell that debian-testing to debian-9 is in fact the same thing Jan 27 14:04:15 feel free to symlink one to the other in the sstate cache Jan 27 14:04:36 or, use uninative, which is designed to solve this proble Jan 27 14:10:06 but when does it change? Is is from some debian update or a yocto update? Jan 27 14:14:07 debian Jan 27 14:14:13 you've gone from debian testing to debian 9 Jan 27 14:14:35 presumably that's the sign that debian testing is starting to freeze for release Jan 27 14:18:48 find */*/recipe-sysroot* -links 1 -type f -print0 | xargs -r0 du -aBM| awk '{sum+=$1} END {print sum}' Jan 27 14:18:48 93090 Jan 27 14:19:16 marquiz: ^^^ - that says we have 900MB of single link files in a sample workdir I tested against :/ Jan 27 14:20:01 huh Jan 27 14:20:12 stale from updates to the master copies? Jan 27 14:20:30 uuh Jan 27 14:21:08 rburton: files we have to copy, then fix the paths in Jan 27 14:21:19 ah Jan 27 14:21:21 ouch Jan 27 14:28:01 and that number is clearly wrong due to rounding Jan 27 14:29:56 hmm, 2.5GB is the answer Jan 27 14:33:07 and 900MB of that are .la files Jan 27 14:33:21 * RP waits for rburton to comment Jan 27 14:33:45 ah, no 91MB Jan 27 14:33:57 shame, that would have been an easy fix Jan 27 14:35:51 RP: NINE HUNDRED Jan 27 14:35:54 oh 91 Jan 27 14:35:55 damnit Jan 27 14:39:15 hmm, 1MB each time something depends on libxml2 or python due to the size of the manifest flle alone Jan 27 14:40:19 why some packages require virtual/libc-native? how to bypass? Jan 27 14:42:52 ptizoom: they shouldn't really, how did you manage to hit that? Jan 27 14:43:26 uhmm, I added meta-debian Jan 27 14:44:23 ptizoom: that was probably your mistake. What do you need meta-debian for? Jan 27 14:45:52 RP: meta-debian is joly good I thought they had prepared good embeded distro... Jan 27 14:47:00 ptizoom: OE provides a perfectly good starting point for an embedded distro. meta-debian has a very specific use case for long term support of old software and you probably don't want it Jan 27 14:47:25 ptizoom: it does some pretty crazy things compared to standard OE Jan 27 14:47:52 RP: something happened in master, or the AB is bust: selftest hangs. Jan 27 14:48:00 https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/811 Jan 27 14:49:18 RP: OK, I will drop it out! But for my sake, is there a way other than adding "BBCLASSEXTEND = \"native\"" every where.... to ignore these libc-native dependencies? Jan 27 14:50:29 ptizoom: no libc-native dependencies should be there at all and BBCLASSEXTEND isn't how you'd fix that anyway Jan 27 14:50:44 rburton: locally too? Jan 27 14:50:58 RP: haven't tried yet Jan 27 14:51:47 rburton: no idea offhand :( Jan 27 14:52:09 RP: this is somewhat requested by openldap-native... Jan 27 14:52:48 ptizoom: meta-debian is so far removed from oe-core that you'll have more luck asking in a specific channel Jan 27 14:53:28 RP,rbuton: ok thanks anyway. Jan 27 14:54:01 (our advice is not to use meta-debian because you think its got the software you want. ie openldap is in meta-oe) Jan 27 15:26:32 do_populate_sysroot_setscene: No suitable staging package found Jan 27 15:26:45 keep getting these lately, what's the deal? Jan 27 15:28:19 RP: I did some more investigation on issues seen yesterday on esdk and the sysinitv/systemd thing. What I see here is that building from scratch (no tmp, no sstate-cache) either the image (core-image-minimal) or the esdk succeeds. Rebuilding the image (preserving tmp and sstate-cache) after configuring for systemd (no backfilling of sysinitv) works as well. On the opposite, after reconfiguration, building Jan 27 15:28:25 the esdk fails as reported yesterday (http://pastebin.com/aQRwd5t3) Jan 27 15:28:48 Hello, trying to add x windows to my image, started with inherit core-image. Added some packages and now trying to add IMAGE_FEATURE x11-sato. Is that supposed to work? Jan 27 15:29:03 Any further test I can volunteer for or should I file on bugzilla? Jan 27 15:45:10 Strike5150: copy core-image-x11 and you'll have an image that starts x and not much else Jan 27 15:46:45 rburton: I want to have a core image without x11, and only add x11 on certain machine tyes Jan 27 15:47:31 gizero: bugzilla time. I think I know what is wrong though and may have a patch to test son Jan 27 15:47:56 kergoth: that shouldn't happen :( Jan 27 15:48:13 rburton: x11-sato image feature doesn't seem to add startx. It seems its dependant on x11/x11-base, or I don't know how to start sato Jan 27 15:48:28 just saw hundreds of them before my build started from scratch Jan 27 15:52:08 RP: the failure seen in build perf test seems to be caused by rm_work Jan 27 15:52:29 unfortunately i have to call it a day Jan 27 15:53:48 marquiz: were you able to reproduce? Jan 27 15:54:03 rburton: i pushed fixes to my contrib branch ed/wic/wip Jan 27 15:54:14 ed2: great Jan 27 15:54:43 rburton: looking at ross/mut I'd say you didn't remove hddimg patchet from there yet. Jan 27 15:54:45 kergoth: different subject, I remember that we had to complicate the multiprocessing code in the cooker parser due to issues with python multiprocessing. Do you remember what the issue was? Jan 27 15:55:06 kergoth: I'm wondering if we can loop back now and simplify Jan 27 15:55:19 ed2: no, i'll do that when i pull your bits Jan 27 15:55:22 IIRC there was a bug in the version of python we were using, but it's been a while. does seem worth revisiting, considering we're on 3 now Jan 27 15:55:36 it's a bit hard to remember now though :) Jan 27 15:55:39 packagegroup-core-x11-base : Depends: packagegroup-core-x11-utils but it is not going to be installed Jan 27 15:56:01 When I add the contents of core-image-x11, I get this error Jan 27 15:56:09 ed2: so ed/wic/wip is everything from you i should be including in mut? Jan 27 15:56:20 rburton: I removed couple of patches, updated some and added new Jan 27 15:56:24 where does packagegroup-core-x11-utils come from? how can I include it Jan 27 15:57:04 rburton: yes, it contains everything that should be included in mut, but before that we should remove my hddimg patchset from there. Jan 27 15:57:18 rburton: if you give me 15 minutes I can do it. Jan 27 16:01:31 ed2: by hddimg you mean the 14 patch series "wic should not rely on hddimg creation'? Jan 27 16:02:24 Figured it out, I can simply install it like package using IMAGE_INSTALL. Why is it not able to automagically pull in the dependancy for those? Jan 27 16:02:26 rburton: yes, and some more that you cherry-picked from my branch Jan 27 16:04:07 rburton: I can prepare branch for you if you want. Jan 27 16:04:53 rburton: why do we split python's standard modules into tiny packages? Jan 27 16:05:36 kanavin: because someone long ago decided it would be good for small systems to let you install the bits you need and not say all the internet parts if you never use them Jan 27 16:06:01 rburton: this is causing a very annoying process of determining which of them any given python software needs in RDEPENDS - build an image, run an image, run the software, fix the failure, repeat a million times Jan 27 16:07:17 kanavin: add python3-modules to the image Jan 27 16:07:26 thats the metapackage for "everything" Jan 27 16:07:40 rburton: is it okay if I add that to dnf.bb ? Jan 27 16:08:43 kanavin: for now, sure. Jan 27 16:09:10 kanavin: the pythondeps script in oe-core will scan a python package to get a list of its deps. recipetool create will use it to prepopulate RDEPENDS. Jan 27 16:09:15 manual review is required, however Jan 27 16:09:19 oooo! Jan 27 16:09:49 kanavin: or, enable the package feed on your build machine and on the target copy packages as you need them. saves the rebuild loop. Jan 27 16:09:59 well, recipetool create will do so if it sees a python buildsystem, that is, i.e. setup.py. not sure if there's a way to trigger it manually if the project uses something else Jan 27 16:10:05 good idea Jan 27 16:10:25 i have PACKAGE_FEED_URIS = "http://flashheart.local/poky-master" in my local.conf, and lighttpd on my build machine sharing the deploy as /poky-master/ Jan 27 16:10:41 obviously you're working on dnf so that won't work so well ;) Jan 27 16:10:47 but you can still scp the packages out of deploy Jan 27 16:16:06 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10982 I'll be happy to help with testing the patch... Jan 27 16:16:07 Bug 10982: normal, Undecided, ---, ross.burton, NEW , building eSDK fails after switching from sysinitv to systemd Jan 27 16:16:49 Question about create_sdk_files - I'm trying to add a _prepend to it from a .bbappend file. The recipe I'm appending to already inherits a create_sdk_files_prepend from a bbclass in another layer. I see that my .bbappend file is getting processed when I run bitbake-layers show-appends but when I run bitbake -e imagename I don't see the content of my create_sdk_files_prepend. Jan 27 16:18:21 Is there something about that funciton that prevents me from prepending to it from another bbappend file or am I just trying to do something impossible? Jan 27 16:20:48 rburton: kergoth: thanks for the hints, I think I call it a day now :) Jan 27 16:22:17 gizero: if you change distro features, we really do recommend you delete tmp for this exact reason Jan 27 16:28:30 kergoth: you'd probably understand how to simplify that code better than I would. Wish I could remember the problem :/ Jan 27 16:29:23 sure, will see about taking a look. i don't remember either offhand, it went through a few versions Jan 27 16:31:35 rburton: uhmmm... I probably missed the suggestions from the docs. But if failures are to be expected, maybe we'd better advice like the sanity checker does on misconfiguration. Anyway here the background was testing if this migrating from sysinitv to systemd can be considered reliable from a eSDK update perspective. Will move on with my test with your advice in place Jan 27 16:34:01 rburton, gizero: its actually a grey area now. Before rss, we did have this working, albeit not widely publisied Jan 27 16:39:56 so, I'm trying to build an image with among other things qtdeclarative without x11, but the build fails with opkg saying «Cannot satisfy the following dependencies for qtdeclarative: *a bunch of x11 libs*» Jan 27 16:40:13 I downloaded the .ipkg and looked at the control file manually, and it doesn't list any of those libraries Jan 27 16:40:17 sandsmark: HAHA! Jan 27 16:40:18 nor are they in the .bb files Jan 27 16:40:27 I just gave up about 6 hours ago Jan 27 16:40:30 hah Jan 27 16:40:43 Trying to do the same thing since Monday Jan 27 16:40:46 haha, ok Jan 27 16:41:18 trying to upgrade an installed device now with the new packages Jan 27 16:41:39 «Depends: libgcc1 (>= 5.3.0), libstdc++6 (>= 5.3.0), qtbase (>= 5.8.0+git0+49dc9aa409), libc6 (>= 2.23)» Jan 27 16:41:44 no x11 there either Jan 27 16:41:59 meta-qt5, 5.8 branch? Jan 27 16:42:18 yeah Jan 27 16:42:39 grepped through the entire source/ directory for the libraries, nothing Jan 27 16:43:09 sandsmark: if you just remove x11 from your DISTRO_FEATURES then bitbake will literally refuse to build anything touching x11 Jan 27 16:43:18 yeah, I have removed it Jan 27 16:43:34 and the package is built without x11, the ipk has no references to anything x11, but opkg still complains Jan 27 16:43:53 sandsmark: try greping the Packages files in tmp/deploy/ipk for these x11 libs Jan 27 16:43:59 I was trying to do the same thing. DISTRO_FEATURES_remove = "x11 wayland" but qt5declarative still tried to link against libglx-xcb or something similar Jan 27 16:44:53 aha; cortexa9hf-neon-mx6sl/Packages:Depends: libx11-6 (>= 1.6.3), libxcb-dri2-0 (>= 1.11.1), libxfixes3 (>= 5.0.1), libxcb1 (>= 1.11.1), libx11-xcb1 (>= 1.6.3), libxext6 (>= 1.3.3), libc6 (>= 2.23), libglapi0 (>= 11.1.1), libdrm2 (>= 2.4.67), libxxf86vm1 (>= 1.1.4), libxau6 (>= 1.0.8), libexpat1 (>= 2.1.0), libxdamage1 (>= 1.1.4), libxdmcp6 (>= 1.1.2), libxcb-glx0 (>= 1.11.1) Jan 27 16:45:03 from grep libx11-xcb1 {*/,}Packages Jan 27 16:47:38 sandsmark: a bit more context should show you which package it is and then you can work it backwards from there Jan 27 16:48:15 sandsmark: I'm going to guess at a precompiled graphics driver or something... Jan 27 16:48:18 yeah, I found it, it seems like there's an outdated qtbase from one of the fsl repos that ruins things Jan 27 16:51:45 they try to be clever with the gl stuff because the imx6sl doesn't have a gpu, but I don't want gl Jan 27 16:58:43 gizero: I have a patch you could test Jan 27 16:59:02 gizero: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=61ac96a1bafbc6ac2c6d4b2db93b09496880a101 Jan 27 16:59:46 gizero: it depends on http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=7120b865755c735e3438d8d53f40c87d9c0f19ca (or drop the workdir param) Jan 27 17:02:19 RP: thanks, btw Jan 27 17:02:27 I feel dumb for not looking in the Packages file... Jan 27 17:02:45 sandsmark: I've been there before ;-) Jan 27 17:02:58 :) Jan 27 17:14:02 Hello - I'm trying to add more files to the linux-firmware package via a .bbappend. Do I want to write "do_unpack_append(){}" to unpack the downloaded RPM File, or is there a different function to implement? Jan 27 17:14:19 Currently, there is no do_unpack, as the SRC_URI for the original package is a git repository. Jan 27 17:15:47 Circuitsoft: not sure what makes you think a git repo doesn't unpack.. unpack means take the sources from DL_DIR to WORKDIR, via whatever appropriate mechanism. a git repo is cloned. Jan 27 17:15:55 without do_unpack, you'd have no sources to use to build at all Jan 27 17:16:10 not ideal naming, perhaps, but that's how it is Jan 27 17:16:15 Circuitsoft: put a .rpm in SRC_URI and set extract=1 and bitbake will unpack it for you Jan 27 17:16:59 RP: going to give it a try, thanks! Jan 27 17:20:04 rburton: I'm doing SRC_URI += "/uri/of/rpm" where it already contains "/uri/of/git/repo.git" Jan 27 17:20:12 But, I'll try that and see what happens. Thanks. Jan 27 17:21:11 that'll work fine. Jan 27 17:21:20 bitbake can unpack any number of sources, there's no limitation Jan 27 17:44:29 Is it not possible to have multiple instances of xyz_prepend () {} in the same recipe? Jan 27 17:44:50 themikenicholson: perfectly fine Jan 27 17:45:26 prepend/append are operations, not part of the name. they're cumulative Jan 27 17:55:29 *facepalm* another recipe in another layer was inheriting the class... The recipe i was attempting to .bbapend to was not getting pulled in at all Jan 27 18:04:12 I wasn't seeing the effects of the _prepend because it was in the wrong place. Sorry for wasting time. Jan 27 18:16:13 RP: came back for a brief moment Jan 27 18:16:26 RP: yes, i was able to reproduce Jan 27 18:16:49 just INHERIT += "rm_work" and bitbake core-image-sato Jan 27 18:31:59 RP: i just fired git bisect run Jan 27 18:39:29 bah, still no go :( Jan 27 18:43:32 there I fixed it Jan 27 18:43:38 removed the fsl ipk repo Jan 27 18:52:46 i'm using BB_FETCH_PREMIRRORONLY = "1" to fetch from my local mirror only. there's a warning about uninative. do i need this? what is this for? Jan 27 18:58:35 Is there something like depexp that shows packages instead of recipes? Jan 27 18:58:56 I have something pulling in linux-firmware, which conflicts with kernel-firmware. Jan 27 18:59:17 I have a few specific linux-firmware- packages pulled in, but none of them conflict with kernel-firmware. Jan 27 19:07:31 How are the root filesystem user account and permissions set up? It used to be that my images would always contain a root account with no password and that account had super user permissions. Now I have to add "empty-root-password" to allow for that account to be created without a password but my root account no longer has su permissions Jan 27 19:08:58 Is there a way to prevent a particular package from being installed? I have a conflict I'm trying to track down. Jan 27 19:09:33 Circuitsoft: in your local.conf file, you can add IMAGE_INSTALL_remove += "" Jan 27 19:16:41 Okay, so I get my conflict when I add linux-firmware-cxgb to my initramfs. In linux-firmware_git.bbappend, I have FILES_${PN}-cxgb = "". Jan 27 19:27:20 my yocto build is refetching and rebuilding linux-yocto-rt_4.8 every single time i build, regardless of sstate cache. any idea how i can debug this? my bbappend file looks like this: http://pastebin.com/ZeYiRYLz Jan 27 19:38:24 miceopede: see bitbake-whatchanged and bitbake -S printdiff Jan 27 19:38:26 miceopede: did you try to use bitbake-diffsigs to see what changed in the siginfo files? Jan 27 19:38:45 @marka i did not. let me try Jan 27 19:39:08 kergoth's method may be easier, I haven't tried that Jan 27 19:39:21 do i need to specify that after my image? (core-image-rt) Jan 27 19:39:41 bitbake-diffsigs is a standalone command, used to diff two different siginfo/sigdata files from your stamps_dir or sstate_dir Jan 27 19:40:17 okay, let me take a look. Jan 27 19:41:31 bitbake -S printdiff does a diffsigs for you. it locates the sstate which is closest to what we want, then diffs that against the current state of things Jan 27 20:49:58 rburton: I've just sent v3 of my patchset: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131937.html Jan 27 23:15:32 hmm, so privsep isn't working with sshd on x32 builds, but works fine otherwise Jan 27 23:17:39 ah, http://linux.debian.bugs.dist.narkive.com/Oec7vwMR/bug-849923-openssh-server-no-login-possible-after-upgrade-on-x32 Jan 27 23:24:56 * rburton is secretly confident that his new plan to solve a long standing autotools pain point is going to actually work this time Jan 27 23:25:05 just fired an overnight build to test Jan 27 23:25:23 good luck Jan 27 23:28:25 its almost out of native land so that's a good start ;) Jan 27 23:28:29 now bed Jan 27 23:28:31 good weekend all Jan 28 02:50:58 RP: finally fixed clang with rss, it works all well now. I will test out SDK sometime over weekend and see how it works, I needed to patch clang https://github.com/kraj/meta-clang/blob/master/recipes-devtools/clang/clang/0004-clang-Do-not-search-clang-install-dir-relative-.-lib.patch **** ENDING LOGGING AT Sat Jan 28 03:00:02 2017