**** BEGIN LOGGING AT Fri Mar 30 03:00:01 2018 Mar 30 07:21:41 good morning Mar 30 07:36:21 morning Mar 30 08:39:27 hello guys. I'm trying to compilke pigpio with bitbake, in order to do so I've modified its original Makefile to https://pastebin.com/BBwz5KNP Mar 30 08:39:59 the compilation process is ok but during do_package I get this error form QA: pigpio-67.0.0-r0 do_package_qa: QA Issue: /usr/bin/pigpiod contained in package pigpio requires libpigpio.so.67, but no providers found in RDEPENDS_pigpio? [file-rdeps] Mar 30 08:40:35 ls tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/pigpio/67.0.0-r0/packages-split/pigpio/usr/lib/ Mar 30 08:40:51 returns: libpigpiod_if2.so.67 libpigpiod_if2.so.67.0.0 libpigpiod_if.so.67 libpigpiod_if.so.67.0.0 libpigpio.so.67 libpigpio.so.67.0.0 Mar 30 08:41:30 Does abyone ahve an idea to solve the issue ? Mar 30 08:48:24 I need help to add a custom driver to a working build. I tried following https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules, but my attempts are ignored (no attempt to compile the module). can someone help? NOTE: I'm a yocto newbie. Mar 30 08:51:49 basically pgpio builds pgpiod and libpgpio, by the way QA seems not to know that Mar 30 08:52:46 fberg: can we see your recipe? Mar 30 08:52:56 yes Mar 30 08:53:27 mcon: are you ZioByte from SO? Mar 30 08:53:38 https://pastebin.com/7tzzzaJR Mar 30 08:55:54 fberg: just a small remark, you should generate a Makefile patch instead of replacing it in do_configure_append Mar 30 08:57:05 you are right but since I'm working on it i do not have to regenrate the patch every time Mar 30 08:57:27 I think you'll need to add those dynamic libraries to FILES_${PN}-libs Mar 30 08:57:56 nayfe: Yes. Mar 30 08:58:33 did you look at my last answer? Mar 30 08:58:43 nayfe: Guilty as charged. Mar 30 09:00:43 nayfe: thanks but id doesn't solve the issue. QA still complaining that /usr/bin/pigpiod contained in package pigpio requires libpigpio.so.67, but no providers found in RDEPENDS_pigpio? [file-rdeps] Mar 30 09:04:36 fberg did you add PACKAGES =+ "${PN}-libs" also ? Mar 30 09:04:59 you can also try RDEPENDS_${PN} += "${PN}-libs" Mar 30 09:05:16 nayfe: I can pastebin (or add to SO) any required info, of course. Just ask (the driver itself is under NDA so I cannot post it, but that shouldn't be necessary). Mar 30 09:07:37 mcon: did you change your source tree to match correct one? Mar 30 09:09:09 mcon: did you try to just "bitbake kernel-module-bcm89359" ? Mar 30 09:15:53 nayfe: I am evidently missing something vital because I get "Nothing PROVIDES 'kernel-module-bcmdhd" (I renamed bcm89359 -> bcmdhd). Mar 30 09:17:12 nayfe: I do not understand, what do you mean by: "did you change your source tree to match correct one?" Mar 30 09:17:15 can you give your updated source tree? Mar 30 09:17:51 your recipe should reside in forgotten place :D Mar 30 09:17:52 nayfe: I will update SO question in a minute.... Mar 30 09:20:34 nayfe: I just saw Your answer in SO. I will update my source tree accordingly. Mar 30 09:25:43 mcon: btw, you should split module sources and yocto recipes :) Mar 30 09:28:13 nayfe: nope :( also with the tree as you posted on SO I get "Nothing PROVIDES 'kernel-module-bcmdhd'." Mar 30 09:28:57 nayfe: one funny thing is I also get, now: "linux-imx RPROVIDES kernel-module-bcmdhd" Mar 30 09:31:21 can you type "bitbake -e | grep ^MACHINE_ESSENTIAL_EXTRA_RDEPENDS=" Mar 30 09:31:23 nayfe: From yocto documentation I understood I do *not* have to put the "kernel-module-" prefix: "... The inherit of module.bbclass will automatically name module packages with "kernel-module-" prefix as required by the oe-core build environment." Mar 30 09:32:33 nayfe: MACHINE_ESSENTIAL_EXTRA_RDEPENDS="" Mar 30 09:32:48 mcon: i prefer to stick on naming conventions Mar 30 09:33:23 did you put your module to rdepends or rrecommends ? Mar 30 09:34:22 nayfe: You mean module.bbclass will automatically add "kernel-module-" prefix if not present but will not complain if it's already there, correct? Mar 30 09:34:40 yes Mar 30 09:36:10 nayfe: I added the line: MACHINE_EXTRA_RRECOMMENDS += "kernel-module-bcmdhd" Mar 30 09:36:32 bitbake -e | grep ^MACHINE_EXTRA_RRECOMMENDS Mar 30 09:36:44 nayfe: ... to my .../build/conf/locl.conf Mar 30 09:39:30 mcon: oe-pkgdata-util list-pkgs -p kernel-module-bcmdhd Mar 30 09:40:05 Hi there ! Is there someone here that can help me to configure my Yocto instance to target a local mirror ONLY (where another Yocto instance is available with sources downloaded) instead of targetting internet? thanks Mar 30 09:40:28 nayfe: ERROR: Unable to find packaged recipe with name kernel-module-bcmdhd Mar 30 09:42:09 bparmentier: BB_FETCH_PREMIRRORONLY = "1" BB_NO_NETWORK = "1" INHERIT += "own-mirrors" SOURCE_MIRROR_URL = "..." Mar 30 09:42:39 mcon: can you update your SO post with new source tree? Mar 30 09:43:12 thanks nayfe but this does not work... my local mirror is another machine on the local network, so if I don't enable network I'm unable to target it Mar 30 09:44:07 don't add BB_NO_NETWORK but BB_FETCH_PREMIRRORONLY should be enough Mar 30 09:46:56 damn! it works! then this is just a configuration on my server side (nginx) Mar 30 09:47:18 thanks a lot Mar 30 09:47:31 np :) Mar 30 09:55:26 nayfe: I updated SO post. Mar 30 09:55:59 New news from stackoverflow: meta-virtualization rocko branch unable to locate docker package Mar 30 10:09:39 maybe try to put your sources into git repo or make a tgz Mar 30 10:12:47 nayfe: I can surely pack everything in a.tar.gz, but I strongly doubt that's the problem. It seems yocto doesn't see my package at all, it doesn't seem to complain because of missing sources. Mar 30 10:14:00 nayfe: In any case: what is the suggested location for the archive? I would like to avoid setting up a ftp server for the purpose ;) Mar 30 10:19:15 nayfe do you know how to configure the server for my local network mirror? Mar 30 10:28:40 Brb lunch Mar 30 10:42:34 hello guys. I have a library (libjsmn) compiled correctly with a custom recipe. Now I have another recipe (c4d) that needs jsmn .h and libjsmn.a. So I have added DEPENDS="libjsm" to the latter recipe. if i go to: tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/c4d/1.0.0-r0/recipe-sysroot/usr/lib/there i libjsmn.a and in usr/include there is jsmn.h. By thw way there isn't any libjsmn.pc in usr/lib/pkgconfig. Since I use pkgconfig to Mar 30 10:42:34 read .h and .a location I can't compile correctly Mar 30 10:43:15 Why including "libjsmn" in depends doesn't generate its .pc ? Mar 30 11:51:52 what do you mean by "how to configure the server for my local network mirror" ? Mar 30 11:54:58 mcon: bitbake-layers show-recipes 'kernel-module-bcm*' Mar 30 11:55:28 nayfe I've installed nginx on the server and I'm not able to fetch / clone from the server with yocto Mar 30 11:57:34 bparmentier: did you look at https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-own-mirrors ? Mar 30 11:57:41 I'm able to get static files from the poky downloads folder, but not git repositories Mar 30 11:57:52 ow Mar 30 11:58:34 you'll probably need to generate tarballs for git repo https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#setting-up-effective-mirrors Mar 30 11:58:46 with BB_GENERATE_MIRROR_TARBALLS Mar 30 11:59:49 this parameter needs to be set in the yocto mirror configuration itself, not in the other yocto instance i'm working on, right ? Mar 30 12:02:24 i think you will need to first populate the local DL with this option (i.e bitbake -c fetchall ) , then copy it to mirror Mar 30 12:02:52 hmmmm ok... i'll try this but not sure to have a correct understanding Mar 30 12:04:03 i would expect that the mirror fetches the sources and generates tarballs, then the local yocto instance could download the tarballs instead of cloning git repos Mar 30 12:07:15 on the mirror yocto, you just fetchall will BB_GENERATE_MIRROR_TARBALLS option and no mirror set, and in local yocto, you set BB_FETCH_PREMIRRORONLY etc .. Mar 30 12:07:40 okay understood thanks ;) Mar 30 12:07:45 but you can also only use one yocto instance with rsync :) Mar 30 12:07:50 or equivalent Mar 30 12:11:16 fberg: does libjsmn have something like FILES_${PN}-dev = " ${libdir}/pkgconfig/*.pc" ? Mar 30 12:15:04 don't know what you mean by only one yocto instance with rsync ? i MUST have one secured instance that has access to internet (entreprise network with no capability to git/ssh to outside), and another on the local network targeting the mirror Mar 30 12:16:44 nayfe: nope, I haven't redefined/added any FILES_*. Mar 30 12:18:33 fberg: that's why you don't have any pc file from DEPENDS Mar 30 12:18:38 i think Mar 30 12:19:46 so it's not an option :) Mar 30 12:20:12 Mmmm.. I'll look into it. I suppposed that bitbake does that transparently Mar 30 12:43:19 nayfe: if jsmn Makefile doesn't create any .pc file, I am suppos to do it manually ? Mar 30 12:49:47 maybe it is easier to patch c4d not to use pkgconfig stuff ? Mar 30 12:51:04 nayfe: Just to know if it is so Mar 30 12:51:28 fberg don't know :) Mar 30 12:51:46 nayfe: me too :) Mar 30 12:55:23 fberg jsmn is based on old plain Makefile or autotools etc ? Mar 30 12:55:39 old Makefile style Mar 30 12:57:36 don't know if there is better solution but you can find how to generate .pc by hand here https://github.com/creytiv/re/blob/master/Makefile with recipe here https://github.com/savoirfairelinux/meta-sfl/blob/master/recipes-connectivity/libre/libre_0.5.1.bb Mar 30 12:58:28 nayfe: thank you, I've found the template there: https://people.freedesktop.org/~dbn/pkg-config-guide.html Mar 30 12:59:17 now let's see if it works Mar 30 13:09:10 nayfe: flawless victory ! Mar 30 13:09:18 gratz ;) Mar 30 13:56:51 New news from stackoverflow: how to compile meta-debin with yocto Mar 30 14:23:26 Getting an error [the basehash value changed from 218f807cf0edad3cca32ef062448e892 to 3d23d00a7078a23327701f5ee0a71458. The metadata is not deterministic and this needs to be fixed], deleting the tmp directory is not a solution, anybody have idea what is causing this issue Mar 30 14:35:31 xtron: share your recipe or any detail :p Mar 30 14:40:21 I'm working on meta-swupdate [rocko], but it is not about specific recipe, deleting the tmp directory solves the issue, but do_compile behave differently in both cases [clean build, delete tmp/] Mar 30 14:41:08 nayfe: ^ might be there is some changing data like [time] Mar 30 14:57:05 New news from stackoverflow: Bitbake: "The metadata is not deterministic and this needs to be fixed" Mar 30 15:20:23 Hi, anyone who have experience with libreoffice package? I would like to add it on my yocto build but there are many many packages missing like "python3-lxml-native" "glm" "glm-native"... I found no where this packages Mar 30 15:21:38 here is the meta-office layer: https://github.com/schnitzeltony/meta-office Mar 30 15:25:24 vladzouth: use the layer index. Mar 30 15:34:21 kergoth: Thanks! but i still have some package like "python3-lxml-native" which isn't on any layer in any branch. but i have python3-native. how can i verify that is suitable? Mar 30 15:35:01 http://layers.openembedded.org/layerindex/branch/master/recipes/?q=lxml Mar 30 15:35:38 python-lxml also emits a -native variant, see BBCLASSEXTEND in http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python/python-lxml.inc#n40 Mar 30 15:35:52 so it''s right there in meta-python Mar 30 15:36:52 kergoth: thanks! Mar 30 15:36:57 np Mar 30 16:36:40 hmm. so one of the comments on a pseudo thing is "and try to build anything" Mar 30 16:37:05 is there an obvious package with the fewest-possible-dependencies that i could use for such a thing? like, the shortest path to "reproduce such a failure" Mar 30 16:37:38 maybe there should be a dummy package that does nothing but "create a single root-owned file in the filesystem, with no dependencies" for this use case. :P Mar 30 16:45:58 ... nevermind Mar 30 16:46:21 it turns out that this problem is widespread enough that basically *anything* more complicated than "run the test program which was supposed to exercise the bug" appears to trigger it. Hah. Mar 30 16:47:11 + /usr/bin/awk => Mar 30 16:47:19 symlinks Mar 30 16:48:17 ... but only sometimes, that's weird Mar 30 16:50:08 seebs: sorry but i dont understand anything you are saying :x Mar 30 16:50:48 i'm debugging a bug i introduced in pseudo Mar 30 16:51:02 the failure mode is that *some*, but not all, path lookups are failing very strangely. Mar 30 16:51:48 the shortest reproducer i've found is that "ls /usr/bin/awk" produces "no such file or directory" because it tries to actually stat "/usr/bin/gawk//" Mar 30 17:02:17 seebs: see what I did in master-next, I added pseudo with the path patch reverted Mar 30 17:02:26 seebs: this still resulted in https://autobuilder.yocto.io/builders/nightly-x86-64/builds/938/steps/BuildImages/logs/stdio Mar 30 17:02:43 seebs: running /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/work/core2-64-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la && /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/work/core2-64-poky-linux/librsvg/2.40.20-r0/recipe-sysroot-native/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders Mar 30 17:03:02 seebs: shows g_module_open() failed for /home/pokybuild/./libpixbufloader-svg.la: /home/pokybuild/./libpixbufloader-svg.la: cannot open shared object file: No such file or directory Mar 30 17:03:21 seebs: so something is funky with the path handling before that commit :/ Mar 30 17:04:18 I don't think we've touched the path handling before that in quite a while. Mar 30 17:04:30 Anyway, I figured out where the problem is, I think. Just double-checking a thing. Mar 30 17:04:43 seebs: ah, I didn't have cwd right. Even then though, g_module_open() failed for /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/work/core2-64-poky-linux/librsvg/2.40.20-r0/build/gdk-pixbuf-loader/./libpixbufloader-svg.la: librsvg-2.so.2: cannot open shared object file: No such file or directory Mar 30 17:06:23 seebs: The more I look at it the more I wonder what caused it, it may not be pseudo but it has to be something in -next :/ Mar 30 17:08:49 seebs: but do_install completes ok without pseudo loaded :/ Mar 30 17:11:38 seebs: will back the pseudo change out and retest as I don't have time right now to poke further Mar 30 17:14:08 okay. i have at least a workaround for the path thing, a proper fix might take a bit longer. Mar 30 17:15:40 but I at least know what's wrong. unexpected breakage that ends up appending one extra slash after each symlink expansion, basically. Mar 30 17:19:22 So, there's a workaround-at-least in upstream now, that appears to fix the path resolution problem for common cases. Mar 30 17:20:12 ... but it breaks at least one other case. okay, i do need to redo this cleanly. Mar 30 18:17:41 so i completely redid a large part of the path processing, and i think it's now simpler and it also seems to work for most cases. Mar 30 18:17:59 commit c7b8f88edea0195f0ef7b24dcdd974783d2d0750. gonna check it out briefly in my local tree also. Mar 30 18:19:25 basically, my initial design where the invariant state was "current path so far always ends with slash" was a bad choice, because you can't stat a path ending in slash unless it's a directory. Mar 30 18:38:51 so, i import all of these "meta-whatever" things, but which one is the one that has the "special sauce" that allows yocto to build an image for my specific processor? Mar 30 19:22:56 AbleBacon: hardware vendors usually provide a "meta-whatever", commonly referred to as a "layer" in OE speak. Mar 30 19:23:02 AbleBacon: see https://wiki.yoctoproject.org/wiki/Newcomers for more details Mar 30 19:23:33 how come "jethro" doesn't have a "meta-poky" folder? Mar 30 19:23:39 i'm not able to build because it's missing that Mar 30 19:24:58 AbleBacon: If you change branches of poky LOTS of metadata will change. You're best off starting a new build directory. Mar 30 19:25:16 ok--thanks Mar 30 19:26:21 e.g.: source ./oe-init-build-env build-jethro Mar 30 19:27:41 AbleBacon: jethro is very old as well, so YMMV Mar 30 19:28:14 well it seems like this processor we're using only has old stuff for it Mar 30 19:28:28 thats unfortunate Mar 30 19:29:03 AbleBacon: what are you working with? Mar 30 19:29:12 cgtimx6 Mar 30 19:29:47 the manufacturer's git doesn't seem to have much that's specifically stuff that they wrote... so i'm hoping i can use some more generic stuff to get a new version going Mar 30 19:30:02 like, most of this is from other projects: https://git.congatec.com/yocto/ Mar 30 19:30:15 so i figure just because congatec hasn't updated their installation scripts doesn't mean i can't get a newer installation, you know? Mar 30 19:30:38 so, how will i know when yocto "recognizes" the "MACHINE" cgtimx6? Mar 30 19:31:10 i'll be installing layers and then at some point, yocto will know about cgtimx6? Mar 30 19:31:26 AbleBacon: that Congatec board is based on the freescale mx6 Mar 30 19:31:30 AbleBacon: should get an error during parsing if you set MACHINE="cgtimx6" Mar 30 19:31:45 and it doesnt exist Mar 30 19:31:45 AbleBacon: I believe the freescale community BSP supports it Mar 30 19:31:54 thanks, stephano Mar 30 19:32:00 AbleBacon: http://freescale.github.io/ Mar 30 19:32:10 i do get that error, clsulliv--but when i'm successful, i shouldn't get that error anymore, right? Mar 30 19:32:47 AbleBacon: right. you will have to add the right layer to your build/conf/bblayers.conf file Mar 30 19:35:39 AbleBacon: it looks like meta-freescale-3rdparty has the MACHINE you're looking for, and they do have branches for recent releases Mar 30 19:35:54 excelennnnnt! thanks! Mar 30 19:36:16 now i just have to get QT to work with it... but that just means adding those layers, right? Mar 30 19:41:12 hmmm i've added "meta-freescale-3rdparty" via toaster but the cgtimx6 doesn't show up in the machines Mar 30 19:42:08 AbleBacon: I have no experience with toaster, so I'll be less helpful here Mar 30 19:42:23 how do i see the list of supported machines from the console, then? Mar 30 19:42:24 AbleBacon: one guess, do you have the base meta-freescale layer added? Mar 30 19:42:32 yes, i have taht as well Mar 30 19:42:57 gonna do "bitbake-layers show-recipes" and see what happens Mar 30 19:43:54 where did you see that freescale supports that machine? Mar 30 19:44:51 AbleBacon: not the machine, just the congatec kernel. Mar 30 19:45:01 oh? Mar 30 19:45:13 https://github.com/Freescale/meta-freescale-3rdparty/blob/master/recipes-kernel/linux/linux-congatec_4.1.15.bb Mar 30 19:45:16 AbleBacon: oh dang, I was actually wrong I think Mar 30 19:45:27 COMPATIBLE_MACHINE = "(cgtqmx6|cgtumx6|cgtimx6)" Mar 30 19:45:38 they have a cgtqmx6 machine but not cgtimx6 Mar 30 19:45:52 no, i see it in that link that stephano just wrote Mar 30 19:45:58 that means it's in there, right? Mar 30 19:45:59 I was looking here: https://github.com/Freescale/meta-freescale-3rdparty/tree/master/conf/machine Mar 30 19:47:18 AbleBacon: I would ask on their mailing list to see if people are currently building for that machine. It will save you a lot of trouble if someone already has this working. Mar 30 19:47:21 AbleBacon: https://lists.yoctoproject.org/listinfo/meta-freescale Mar 30 19:48:52 thanks Mar 30 19:49:06 mailing list very old-school Mar 30 19:51:36 AbleBacon: Also, check the congatec site for your board. I don't know what you're using, but both their MX6 boards have builds off of Morty. Mar 30 19:53:45 stephano: he linked their git repos. It looks like they're using their own forks of some stuff Mar 30 19:55:41 is that what they're doing with those? those are forks? Mar 30 19:56:00 they have a cgtqmx6.conf that's just a symlink to cgtimx6.conf, and they've modified cgtimx6.conf Mar 30 19:56:32 ah--so it's the ".conf" file that determines it can do a certain machine, then? Mar 30 19:56:53 clsulliv: yeah, they "support" android, yocto, and windows ce. i think i've run across them before. Mar 30 19:58:23 AbleBacon: right, you can check conf/machine/* for machine definitions Mar 30 20:59:57 Is there a way to list all the missing dependencies instead of having to resolve them one at a time Mar 30 21:22:41 seebs: fwiw, reverting the pseudo upgrade is making -next much happier. Were there multiple path commits or have I found some other issue? Mar 30 21:32:21 There was exactly one path thing specifically, the thing after that is the syscall wrapper. There's now a couple more patches that, taken together, replace the path code with something more stable. Mar 30 21:32:45 I'm not sure what commit you're on after "reverting". Mar 30 21:33:40 There's a March 1 patch for a race condition, which *should* reduce some causes of host contamination in cases where CREAT is creating a file which matches one already in the database. Mar 30 21:43:55 seebs: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=f9f71e5a1bbdf330c7073618c935a059e9612e8d is what I tested which is master with the one patch reverted Mar 30 21:44:24 seebs: well, it was head of master at the time, the syscall patch minus the path changes Mar 30 21:48:44 i'm a bit confused by the gistfile1.patch, which looks to me like something that's already in master right now. Mar 30 21:49:32 I also finally merged the sticky bit fix, which apparently got lost in the shuffle a while back. Mar 30 21:59:01 seebs: FWIW, all my tests on FC27 have worked with the rename patch (although I applied it as a single patch on d7c31a25e4b02af0c64e6be0b4b0a9ac4ffc9da2, current pseudo SHA1 in oe) Mar 30 21:59:56 seebs: It also works on morty when applied similarily :) Mar 30 22:38:36 seebs: hmm, so you think its mismatched patches? Mar 30 22:39:02 seebs: possible I guess, I'll poke further Mar 30 22:42:31 seebs: gistfile1.patch isn't being applied Mar 30 22:46:56 armpit: are you around? can you please merge patch for python3-pytest I just sent to mailing list? Mar 30 22:49:03 yeah.. physically not mentally.. will do Mar 30 22:49:48 armpit: i can merge too, but don't what to break anything on your end Mar 30 23:13:27 Huh. I don't know. My current commit passes simple tests for me, and I don't have enough hardware to do more. Mar 30 23:19:18 armpit: thank you! you're a gem Mar 30 23:34:27 khem: hmm, if there are multiple revs/names for a single repo with multiple specified shallow since dates (unlikely, but possible), fatally error? Mar 31 00:00:35 khem: fyi, looks like shallow since requires both a new git client *and* newer git on the server side when using git://. limits the usefulness somewhat, though still worth supporting, ki think Mar 31 00:23:59 kergoth: I agree, the repos getting huge there will be incentive to update git Mar 31 01:18:57 Hi. I'm trying to add connmanctl to my image. Adding connman-conf to CORE_EXTRA_IMAGE_INSTALL works, but adding it into a package group does not with errors complaining about "nothing provides connman-conf" in do_populate_sdk. What could be the difference? Mar 31 01:30:44 rschaefe: the recipe does not BBCLASSEXTEND = "nativesdk" Mar 31 01:30:48 https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#ref-classes-nativesdk Mar 31 01:32:50 not sure it makes sense to add it to SDK, but I'll leave that for someone else to comment on Mar 31 01:33:24 khem: https://github.com/openembedded/bitbake/compare/master...kergoth:shallow-since only barely tested due to the aforementioned version issues, but seems like it should do. 1) BB_GIT_SHALLOW=1, 2) BB_GIT_SHALLOW_SINCE or BB_GIT_SHALLOW_SINCE_ to a date before SRCREV commit, optionally, on a per-recipe basis 3) BB_GENERATE_SHALLOW_TARBALLS=1 Mar 31 01:35:37 only uses it on the initial clone, which is then converted to full on an as-needed basis Mar 31 02:08:35 moto-timo: thanks! my computer forced restarted on me. Are packagegroups always included in the sdk? I can't see anywhere where I accidentally included the packagegroups in TOOLCHAIN_[HOST|TARGET|_TASK Mar 31 02:10:48 rschaefe: packagegroups are mostly a convenience for image creation Mar 31 02:10:49 https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#usingpoky-extend-customimage-customtasks Mar 31 02:11:21 no recipe will end up in an SDK unless it BBCLASSEXTEND = "nativesdk" Mar 31 02:11:41 (I think fairly strongly) **** ENDING LOGGING AT Sat Mar 31 03:00:01 2018