**** BEGIN LOGGING AT Tue Jun 21 02:59:58 2016 Jun 21 06:33:59 hi. i have a bunch of layers in bblayers.conf. i have to manually enable/disable them depending on the current machine type. Jun 21 06:34:12 is there any way to automate this? Jun 21 06:34:50 like: if machine == "raspberrypi" then BBLAYERS += "./meta-raspberrypi" Jun 21 06:45:46 seems like they're mixed together in the wiki page Jun 21 06:49:34 okay, it's yocto manual that has the stuff about making a patch file Jun 21 06:49:54 oe wiki has the other way Jun 21 07:02:12 ionte: I have a similar setup using things like BBMASK =""${base_conditional('MACHINE', 'mach, '', 'meta-mach', d)}" in local.conf Jun 21 07:02:21 but I am not very happy with the results Jun 21 07:03:19 .inc files can still be included across layers; see discussion a few days ago: https://www.yoctoproject.org/irc/%23yocto.2016-06-15.log.html#t2016-06-15T17:34:06 Jun 21 07:05:03 fredcadete: ok :( Jun 21 09:45:31 hi guys Jun 21 10:06:01 i'm trying to generate a sdk. actually i just added "inherit populate_sdk" in my software recipe. in this recipe there is a lot of dependancies that i can't find in the generated sdk (bitbake myrecipe -c populate_sdk). is there a way to have all the dependancies met? Jun 21 10:11:11 s54b32: are your dependancies indicates in RDEPENDS in your recipe? Jun 21 10:15:31 clement: not all, some of them are in DEPENDS, the other ones in RDEPENDS_. For example, i have libxml2 & libyajl in DEPENDS, and when browsing the sysroots, i'm able to find libxml2 but no libyajl Jun 21 10:32:16 s54b32: yes this is strange Jun 21 10:35:43 s54b32: what do you have in tmp/work//libyajl//sysroot-destdir ? Jun 21 11:31:52 what layer is the openssh-sftp-server recipe defined? Jun 21 11:37:14 CTtpollard: oe-core - as part of openssh : http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-connectivity/openssh/openssh_7.2p2.bb?h=master Jun 21 11:37:53 maxin: thanks Jun 21 11:38:04 my grepping was failing Jun 21 11:39:06 what enforces openssh-sftp-server there? my system has openssh support Jun 21 11:40:54 CTtpollard: sorry, didn't really get the question.. you mean, how do we install it or ? Jun 21 11:44:23 maxin: I presumed openssh-sftp client/server would have a recipe defined somewhere Jun 21 11:44:42 is it possible to build toolchain with static libraries without including those libraries in image itself? Jun 21 11:44:50 currently I use SDKIMAGE_FEATURES_append = " staticdev-pkgs" Jun 21 11:45:02 and TOOLCHAIN_TARGET_TASK_append where I add -staticdev packages that I need Jun 21 11:45:12 then I use -c populate_sdk Jun 21 11:45:40 but I don't need those packages and libraries in image since I push my application as one static binary Jun 21 11:45:57 should I just create two images, one for device and one for toolchain or? Jun 21 11:47:37 CTtpollard: sftp is part of openssh Jun 21 11:52:02 clement: i don't have any sysroot-destdir inside /libyajl/*, but it does exist inside /libxml2/* Jun 21 11:57:39 i simply added inherit populate_sdk in my recipe but it's not working. Jun 21 12:03:11 s54b32: have you try to build the sdk for your entire image (not just for your recipe)? Jun 21 12:07:10 rburton: ok, so if I just image append, or define a packagegroup with openssh-sftp-server, it will compile the openssh package with sftp enabled? Jun 21 12:07:27 clement: no, what i wanted to do is to have a sdk only for the particular recipe, so i'll be able to build my software directly from the sdk Jun 21 12:08:05 i'ma try to clean the tmp directory & re-run the sdk generation, not sure my environment is clean Jun 21 12:12:00 CTtpollard: sftp is always enabled, just packaged separately Jun 21 12:23:10 s54b32: ok i see, i just tried to build yajl and i got libs into my sysroots, can you pastebin your recipe? Jun 21 12:51:16 clement: actually yajl != libyajl Jun 21 12:51:35 s54b32: ;) Jun 21 12:54:13 s54b32: but recipe yajl build libyajl Jun 21 12:57:23 clement: definitely, but both of them are missing sysroot-destdir directory, can't figure out why Jun 21 13:00:54 s54b32: if you try: bitbake -f -C fetch libyajl (or yajl), do you have it in sysroot? Jun 21 13:03:20 clement: no, i'ma clean the tmp dir & the sstate cache dir as well Jun 21 13:18:38 Hello Jun 21 13:19:23 What is the best way to make a task that in a recipe that is executed whenever virtual/kernel got rebuilt? Jun 21 13:20:15 I would like to make sure do_make_scripts from modules.bbclass is retriggeed whenever the kernel was rebuilt Jun 21 13:57:11 hi. I have a question about useradd.bbclass usage Jun 21 13:58:15 if I have 2 recipes where I want to change ownership of directories to let's say: www user - do I have to use "useradd" iheritance in both recipes and create a user in both of them?? Jun 21 13:58:42 or is there a different way to handle that? Jun 21 14:27:39 How does bitbake know that it has to re-execute do_compile of an external kernel module if the kernel was recompiled? Jun 21 14:34:11 hi guys, how can I resize the hddimg? Jun 21 14:34:20 I need more free space Jun 21 14:34:48 it can be done after dd on the device? Jun 21 14:35:08 i tried parted and resize2fs but none worked Jun 21 14:37:16 http://www.crashcourse.ca/wiki/index.php/Poky_Variable_Glossary#IMAGE_ROOTFS_SIZE Jun 21 14:37:34 thanks sir Jun 21 14:38:05 also IMAGE_ROOTFS_EXTRA_SPACE which is there too Jun 21 14:48:13 bachp: task dependencies, I'd say. do_compile transitively depends on the task that installs the kernel headers in a shared workdir, and the hash of this task changes, forcing the kernel module to be recompiled Jun 21 15:03:22 neverpanic: how could I make bitbake execute the do_make_scripts as well? Jun 21 15:35:16 bachTAB: Give it the same task dependencies. Jun 21 15:49:49 Hello Jun 21 16:05:19 I have a bunch of images I want included in my package. Is there a way to include all these images without singling each out in do_install? Jun 21 16:23:05 create a packagegroup or create rdepends on each other Jun 21 16:46:00 hi everyone Jun 21 16:48:46 my company (in chicago) is developing a product using yocto, and we need to hire additional help. Yocto is not really a keyword we're finding on resume boards so I was wondering if anyone had any ideas of how I can network with the right people Jun 21 16:49:50 yocto4: would a consultancy company be an option? Jun 21 16:55:53 no we want to hire a permanent internal resource Jun 21 16:56:49 ok Jun 21 16:57:18 I think you'd have to use the usual methods for acquiring such a resource. job postings wouldn't be kosher on the lists, so I'd say linkedin and whatnot Jun 21 17:00:43 I'm trying to learn about yocto and I find it very confusing Jun 21 17:01:37 is there a "recommended" way of keeping stuff like bblayers.conf and local.conf in source control? Jun 21 17:02:59 yocto4: did you have anyone in-house you can train? Jun 21 17:03:25 those are isolated to a particular build, si i wouldn't recommend putting them in source control at all. you could use a custom set of templates for them which would be used when you source teh setup scripts if you set TEMPLATECONF Jun 21 17:03:47 i think most do something like that, or address further customizations via the build scripts, i.e. write out an auto.conf with further tweaks Jun 21 17:04:28 what is auto.conf? Jun 21 17:04:58 it's a config file specifically intended for use by autobuilders and whatnot Jun 21 17:05:16 from what I understand "poky" is just an example distro, but it seems to be a complex confusing example Jun 21 17:05:17 if it exists in bbpath, it'll be sourced. most commonly placed next to local.conf and bblayers.conf Jun 21 17:05:32 the poky *repository* is an integration of components, and differs from the poky *distro* Jun 21 17:05:42 the repo is bitbake + oe-core + meta-poky + meta-yocto-bsp / etc Jun 21 17:05:53 you could use the components yourself directly, or the poky repo Jun 21 17:06:07 you could create your own distro, or base on the poky distro, but that's independent of the repositories involved Jun 21 17:06:12 (the distro lives in meta-poky) Jun 21 17:06:26 there's been a proposal recently to address this naming confusion, we'll see if it pans out Jun 21 17:06:34 using the components myself sounds tempting, but I see that poky doesn't use submodules Jun 21 17:06:47 instead there are some scripts which merge git repos Jun 21 17:06:54 it uses the combo-layer tool, which pulls in the commits directly into a single standalone repo Jun 21 17:06:55 yes Jun 21 17:07:03 is there an alternative example to poky using just pure submodules? Jun 21 17:07:06 submodules and repo are commonly used tools Jun 21 17:07:28 like i said, you could pull in the same components as poky with submodules trivially, not much need of an example, really :) Jun 21 17:07:42 but i'm sure there are lots of submodule and repo based setups on github Jun 21 17:07:57 there's no single tool for multiple repository management, as the requirements and use cases differ Jun 21 17:08:19 cdleonard: this might help get a leg up => https://github.com/VCTLabs/scale13x-presentations/blob/master/bin/yocto_scale_handout_notes.pdf Jun 21 17:08:44 the 'repo' tool which is used in android is used by some of us, the advantage to it is it can track a branch rather than a commit, so you don't have to check in update commits to the main repo every time you update the individual child repositories the way you have to with submodules Jun 21 17:08:47 https://github.com/VCTLabs/vct-beagleboard-bsp-platform <= manifest example Jun 21 17:08:53 nerdboy: nice Jun 21 17:08:54 so you're saying it would work easily? start from an empty repo and add a bunch of git submodules and have it build something useful? Jun 21 17:09:00 cdleonard: yep Jun 21 17:09:23 nerdboy's presentation link looks useful Jun 21 17:09:29 repo is both cool and annoying sometimes Jun 21 17:09:48 * kergoth has both submodule and repo based setups in his github account, depending on what he's in the mood to mess with :) Jun 21 17:10:14 submodules are similarly cool and annoying... Jun 21 17:10:33 when i do use submodules, i like to combine it with the myrepos tool for convenience. but you're still stuck with lots of overhead commits in the main repo Jun 21 17:10:47 * nerdboy uses both, depending on "annoyance" needs/requirements Jun 21 17:10:53 repo being xml for its manifest makes me sad, but i can't deny it does the job fairly well Jun 21 17:10:59 the fact that it floats your checkouts by default annoys some folks Jun 21 17:11:26 i almost never use repo init directly when setting up my projects, i use a 'newproject' script that inits, syncs, and starts a branch for the project name in all the repos, so they're never floating checkouts :) Jun 21 17:12:19 yeah, same idea here Jun 21 17:12:36 yet-another-wrapper-script... Jun 21 17:13:04 hello all Jun 21 17:13:57 I like subtree & friends for the vendor sources use case. i.e. your simpler project uses an external module or lib and needs it vendored. but for a case like an oe/yocto build it's not like that, it's a product made out of many dispirate pieces, any number of which you'll need to check into, which is basically what repo is designed to handle for android Jun 21 17:15:25 honestly between git submodules/repo/combo-layer the latter seems to be the most confusing Jun 21 17:15:32 I have and image on a raspberry pi 3 and I would like to add libc6-dbg for valgrind is there way to do that with out creating a new images Jun 21 17:16:43 I'm used to having a single repo which can build images for multiple boards (on multiple architectures) Jun 21 17:17:04 the way to replicate this with yocto would be have a separate top-level script which creates multiple build dirs? Jun 21 17:17:57 that's kinda the default anyway Jun 21 17:18:18 *without jiggering paths in config files and such Jun 21 17:18:55 it's confusing because the intention seems to be for local.conf to be 100% owned by the user Jun 21 17:19:00 so yes, setup local.conf to put sstate-cache and downloads in one place Jun 21 17:19:27 then oe-init build-arch-foo/ for each build Jun 21 17:19:35 cdleonard: like i said earlier, you can change the template used for local.conf and bblayers.conf, which will control the files copied into the build dir when the setup script is sourced Jun 21 17:19:49 but yes, generally local.conf is intended to be able to be modified by the user, that's why it exists Jun 21 17:20:20 so the recommended way would be to create templated bblayers.conf/local.conf for specific supported boards, right? Jun 21 17:20:39 does a template bblayers.conf still fit into a layer? Jun 21 17:21:07 cdleonard: note you can override almost anything in local.conf Jun 21 17:21:07 set preferred kernels, etc Jun 21 17:21:43 if you use repo it can handle the extra config files for you Jun 21 17:22:03 eg, fsl-community-bsp Jun 21 17:23:15 yeah but I'm looking for a "good way" to keep that config in source control Jun 21 17:23:40 I assume that user changes to local.conf should mostly be used for development/debugging purposes Jun 21 17:25:23 not sure what you're asking Jun 21 17:26:06 changing your 'board' is just a matter of setting one variable in local.conf, generally. or the environment Jun 21 17:26:08 MACHINE Jun 21 17:26:13 local.conf is specifically for local config (machine=) and customizing so you don't have to change several other .conf files, etc Jun 21 17:26:32 most of your configuration will reside in teh machine .conf for each bsp/machine and the distro .conf, which is under your control in your own layer, generally Jun 21 17:26:46 doing as little as possible in local.conf, other than providing the user examples of how to change certain things, is best Jun 21 17:26:53 if you need to change more than that, making a custom layer is probably indicated Jun 21 17:28:30 so I should make my own layer and keep any persistent conf files in there as templates Jun 21 17:30:19 and for a top-level checkout the easiest way would be to fork the poky repo and add my layer as a submodule? Jun 21 17:30:21 that would work, yes, or, again, do more configuration in the distro rather than the template local.conf/bblayers.conf Jun 21 17:30:21 or both Jun 21 17:30:48 I'm scared that if I attempt to replicate the top-level poky directory structure I'll chase a lot of obscure issues Jun 21 17:32:16 https://gist.github.com/sarnold/9bd57ac916f361d7faa8868c63f9276d <= somewhat extreme example Jun 21 17:32:18 let's say I want to get this to run with my own kernel branch. Would it be reasonable to add the kernel as a submodule? Jun 21 17:33:07 your own kernel branch should probably be done via a .bbappend Jun 21 17:35:32 right. would it be sensible to have the .bbappend point to the submodule checkout? Jun 21 17:38:44 where does the submodule come in? Jun 21 17:39:45 the bbappend would sit your own (slim) layer and append whatever recipe (yocto-linux) you're using Jun 21 17:40:19 inside it pints src_uri to repo location and branch=your-branch Jun 21 17:40:25 *points even Jun 21 17:42:12 yeah, generally the recipe fetches the kernel, rather htan fetching it with your repository management setup and pointing it to a local path Jun 21 17:42:28 I was thinking of having the kernel itself as submodule (for example in my-poky/linux-kernel) and have my layer point to it (as src_uri) Jun 21 17:43:29 also, what if I want to build the same kernel source for multiple arches/platforms, won't it be checked out multiple times? Jun 21 17:44:05 no, the DL_DIR goes by the url Jun 21 17:44:14 local checkouts for each Jun 21 17:44:19 indeed Jun 21 17:44:33 dl folder gets one git repo Jun 21 17:45:24 I'm confused, "local checkouts for each" seems to be the opposite of "dl folder gets one git repo" Jun 21 17:47:42 what I'd like is a single kernel source tree built for multiple platforms. And that should be a real source tree that I can edit and manipulate with common git commands Jun 21 17:47:51 is there an easy way to do this? Jun 21 17:49:45 cdleonard: no, you're mixing up checkouts and clones Jun 21 17:50:01 git supports 1. multiple work trees for a single git repo, adn 2. local clones which share the same objects, so files arent' duplicated Jun 21 17:50:12 cdleonard: some packages like gcc uses a shared source tree but generally you need seprate checkouts for separate builds Jun 21 17:51:19 you can also use a shared source tree for the kernel, what you're saying is that yocto doesn't do that? Jun 21 17:53:20 its usually done as exception Jun 21 17:53:50 to clarify, the source tree in the DL_DIR will be shared regardless Jun 21 17:53:59 it's just there's a fresh clone *from that* when building the kernel recipe Jun 21 17:54:04 thats true Jun 21 17:54:15 what khem is talking about for gcc is a single source tree in the bitbake build that's available for use by multiple recipes, which is a little different Jun 21 17:54:23 different machines will reuse the DL_DIR Jun 21 17:54:29 when DL_DIR points to same dir Jun 21 17:54:36 is DL_DIR a bare repo? Jun 21 17:54:37 useful, but regardless we're not doing massive fresh clones with duplicated files for each machine Jun 21 17:54:40 yes Jun 21 17:54:57 bare clones are made to the download dir which are then cloned from when unpacking the kernel recipe Jun 21 17:56:16 linux-libc-headers.inc says "This does mean your recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and makes total sense." but seems like as of yocto-1.8 (commit 46cdaf1) we are suppose to use do_configure[depends] += "virtual/kernel:do_shared_workdir" instead? Jun 21 17:56:26 Is the libc-headers.inc just outdated? Jun 21 17:56:52 I think I got burned by kernel source not being in the sstate cache properly. Jun 21 17:57:01 yeah, i expect the comments in there are just outdated Jun 21 17:58:10 virtual/kernel:do_shared_workdir is only needed for kmods Jun 21 17:58:50 I have a userspace app that expects a new header file that is only in our custom kernel. uapi for custom driver. Jun 21 17:58:55 So not quite a module. Jun 21 18:01:33 I'll give it a go and see if this fixes it. Jun 21 18:01:53 kergoth: Think I should submit a patch for those comments? Jun 21 18:08:08 Yep, that fixed it. Jun 21 18:09:37 so, the .gitignore in poky has line with "meta-*/" Jun 21 18:10:15 If I want to add extra layers as submodules should I add !meta-mylayer or something? Jun 21 18:13:49 either don't use poky, or put your layers a level above it, rather than inside it Jun 21 18:13:54 or better yet, both Jun 21 18:15:36 so forking poky this way is not recommended? Jun 21 18:20:32 hello is there a way to create a libc6-dbg with bitbake Jun 21 18:21:00 can you point to a good example of a poky-like distro built entirely with submodules? that might be what I'm looking for Jun 21 18:22:33 anyone can help Jun 21 18:22:40 ephlodur: every recipe always emits -dbg packages, i don't understand the question Jun 21 18:22:52 every bitbake build is giong to emit a glibc dbg package.. Jun 21 18:22:59 well, any non-trivial build Jun 21 18:23:59 I want to use valgrind and the from what I get from google search I need to install libc6-gdb to get the app symbols for back trace Jun 21 18:26:06 where would I find those packge to install without creating a new images with out adding dev-pkgs Jun 21 18:28:15 btw when I try to building a new image with dev-pkgs I get opkg_install: Cannot install package bcm2835-dev. Jun 21 18:29:08 ephlodur: get it from the outputs of your build? It should be in tmp/deploy but where exactly depends on your setup Jun 21 18:29:14 cdleonard: I don't know if it is a "good" example, but our repository has poky as a subtree. Jun 21 18:29:22 github.com/openbmc/openbmc Jun 21 18:29:46 dev-pkgs != dbg-pkgs Jun 21 18:32:24 ok .. thanks .. I will try building with dbg-pkgs Jun 21 18:35:51 "either don't use poky, or put your layers a level above it, rather than inside it" Jun 21 18:36:06 that openbmc example is how you put your layer above it? Jun 21 18:36:20 basically symlink the poky-provided layers? Jun 21 18:38:13 stwcx: it seems to me that you basically copied all of poky inside a subdirectory, right? Jun 21 18:38:50 cdleonard: We use 'git subtree' to import poky into that subdirectory and then symlink critical parts back out to the top-level. Jun 21 18:39:35 cdleonard: So it is a cross between a sub-module and a copy. We can use 'git subtree pull' to sync up with later Yocto releases as needed. Jun 21 18:41:29 thanks it build ok .. but I'm not sure what package I hsould intall to get the libc-dbg Jun 21 18:41:57 libc6-dbg or glibc-dbg. the latter is the package name according to bitbake, theformer what it gets renamed to by the shared library renaming Jun 21 18:42:13 did you bother looking for it? find tmp/deploy -name \*libc\*dbg\* Jun 21 18:43:12 I look in deploy .. could not find any libc6-dbg Jun 21 18:44:09 › find tmp/deploy -iname \*libc\*dbg\* Jun 21 18:44:10 tmp/deploy/ipk/core2-64/linux-libc-headers-external-dbg_1.0-2015.12-133-r0.1_core2-64.ipktmp/deploy/ipk/core2-64/libc6-dbg_2.22-2015.12-133-r0.3_core2-64.ipk Jun 21 18:44:13 took me about two seconds to find it Jun 21 18:44:16 don't know what to tell you Jun 21 18:45:28 I found it in tmp/deploy/ipk/cortexa7hf-neon-vfpv4/ Jun 21 18:46:44 thanks a lot for your patience Jun 21 18:53:07 stwcx: so it seems to be like a copy except it keeps some metadata in commit messages. interesting Jun 21 18:53:23 cdleonard: Yes. Jun 21 18:53:49 We did that so that we have a stable snapshot of yocto to do CI testing against. Jun 21 19:02:29 it seems poky is build from it's component repos using combo-layer and this config: https://git.yoctoproject.org/cgit.cgi/poky-config/tree/combo-layer.conf Jun 21 19:03:00 is there anything in the poky repo itself which doesn't come from one of those repos? Jun 21 20:46:46 I have a bunch of files I want included in my package. Is there a way to include all these files in my image without singling each out in do_install? Jun 21 20:55:24 Just a collection of png files, and the file names might change overtime, so I would like to avoid naming each file in the recipe. Jun 21 20:59:03 nillerbrun: Using a wildcard to install them is not an option? Jun 21 20:59:14 the yocto autobuilder doesn't run ptest, does it? is there some other system which runs ptest on a semi-regular basis or is it mostly for development use? Jun 21 20:59:52 neverpanic: doesn't seem to work, but I'll keep trying if you think it should, thanks Jun 21 21:00:36 nillerbrun: it really depends on where those files come from and where they are (e.g. in $S, or just on $WORKDIR because you list them in $SRC_URI) Jun 21 21:07:24 f Jun 21 21:21:14 nillerbrun: you would do something like cp -a ${S}/*.png ${D}/usr/share/ Jun 21 21:21:19 in do_install() Jun 21 21:21:39 then add FILES_${PN} += "/usr/share/*.png" Jun 21 21:21:48 for packaging needs Jun 21 21:22:01 cdleonard1: it should be running ptest yes Jun 21 21:22:05 aha, thanks khem Jun 21 21:32:55 khem: where exactly? I'm looking at this: https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/842 and all I see is some "SDK sanity tests" Jun 21 21:33:58 I think the images are all running ptest Jun 21 21:34:10 may not be all builds but IIRC most of them ran ptest **** ENDING LOGGING AT Wed Jun 22 02:59:58 2016