**** BEGIN LOGGING AT Wed Sep 28 02:59:58 2016 Sep 28 08:44:47 I'm getting "/etc/profile: line 34: test: too many arguments" at bootup now... Sep 28 08:45:25 it's base-files: restrict resize to run on serial consoles only in profile │· eef3fb99d0e3f52ffb5d8676f9ac11e546aad511 Sep 28 10:03:25 Saur: you're interested in meson? Sep 28 10:05:13 rburton1: Well, not me personally, but I have firmware developers who want to use it. They are building pinos, which apparently use a mix of autotools and meson... Sep 28 10:05:33 Saur: if you have users, i have a recipe that needs finishing and testing Sep 28 10:06:06 rburton: I would have expected a bbclass... Sep 28 10:06:17 well, a recipe to build meson is the first step ;) Sep 28 10:06:28 rburton: Ah, of course. :) Sep 28 10:06:39 i have a class too Sep 28 10:06:53 i'll remove the swearing from it before pushing Sep 28 10:07:10 lol Sep 28 10:07:14 hah Sep 28 10:13:42 Saur: github:rossburton/meta-ross, in recipes-devtools Sep 28 10:18:29 I'm adding a new ISA revision. mipsisa32r6el. The path for ld.so.1 has changed to ld-linux-mipsn8.so.1 Sep 28 10:18:29 I've made the changes in meta/classes/linuxloader.bbclass and meta/recipes-core/glibc/glibc-ld.inc but my rootfs still seems to be searching for ld.so.1. Sep 28 10:18:29 When i symlink ld.so.1 -> ld-2.23.so, init works and rootfs works. Sep 28 10:18:29 The symlink ld-linux-mipsn8.so.1 -> ld-2.23.so is present. But it looks like binaries aren't looking in the right place. Sep 28 10:18:29 Any ideas? Have resorted to a rm tmp -rf and doing a clean build. Sep 28 10:24:34 rburton: I'll hand it over to my developers and see if they can make anything out of it. The bbclass seems a bit limited, given that it hardcodes the target architecture to arm (and we use mips). ;) Sep 28 10:25:28 Saur: i did say finishing :) Sep 28 10:25:34 :) Sep 28 11:04:37 is it safe to edit local.conf while bitbake is running? Sep 28 11:04:55 I'm not a patient person Sep 28 11:11:13 apparently not Sep 28 11:13:47 (no major issues, but it re-read it when trying to create the rootfs apparently, and missed some packages) Sep 28 13:27:33 hello, I have been wondering...this sounds really stupid, but has anyone ever accomplished building a Yocto distro using a Yocto distro as host or does OE actually lack some recipies for that? Sep 28 13:30:21 it should work Sep 28 13:38:17 inception.. Sep 28 13:38:46 for a long time it was actually tested Sep 28 13:38:53 (search for build appliance) Sep 28 13:39:11 and the buildtools tarball is basically all the host dependencies built by OE Sep 28 13:51:33 rburton, good to hear Sep 28 13:52:55 now I actually have a "real" problem and question... I somehow fail to include jansson library into my qt sdk Sep 28 13:53:10 TOOLCHAIN_TARGET_TASK += "libv4l-dev libjansson-dev" Sep 28 13:53:15 does not work Sep 28 13:53:34 although I know for a fact I am able to build the development package Sep 28 13:53:59 libjansson-dev-2.4-r0.cortexa7hf_vfp_neon.rpm Sep 28 13:54:58 the approach of including development dependencies actually worked for v4l Sep 28 13:55:46 does that rpm actually have anything in it? Sep 28 13:55:51 I feel something is wrong with the naming here, but not really sure what Sep 28 13:56:51 yeah...headers, pkg-config file and shared library Sep 28 13:57:10 use -e to verify that TOOLCHAIN_TARGET_TASK actually gets set to what you want Sep 28 14:01:26 most likely you need to set it to the pre-debian-renaming names, not post. if the recipe is called 'jansson', then jansson-dev, not libjansson-dev, or bitbake won't know how to satisfy the rdep Sep 28 14:01:27 * kergoth yawns Sep 28 14:04:34 WARNING: No bb files matched BBFILE_PATTERN_wr-template '^/home/mhatle/git/lpd/wr9-base/layers/wr-template/' Sep 28 14:04:34 WARNING: No bb files matched BBFILE_PATTERN_wr-base-dl '^/home/mhatle/git/lpd/wr9-base/layers/wr-base-dl/' Sep 28 14:04:34 WARNING: No bb files matched BBFILE_PATTERN_wr-kernel-dl '^/home/mhatle/git/lpd/wr9-base/layers/wr-kernel-dl/' Sep 28 14:04:39 d'oh wrong window.. Sep 28 14:06:01 kergoth, thanks... now it's trying to build...that is probably correct Sep 28 14:06:39 kergoth, still I am not sure..where I was supposed to look that naming up? Sep 28 14:07:40 the recipe, specifically the PACKAGES and PACKAGE_DYNAMIC variables tell bitbake what packages are going to be emitted Sep 28 14:08:23 but generally you don't need to manually add -dev packages to the sdk, just add the regular package and it'll automatically add all the -dev/-dbg packages associated with it, or use an image that already has it with your -c populate_sdk Sep 28 14:09:03 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/jansson/jansson_2.4.bb Sep 28 14:09:19 I see no PACKAGES and PACKAGE_DYNAMIC Sep 28 14:09:28 or is it wrong file? Sep 28 14:11:42 they're defined by default for all recipes in meta/conf/bitbake.conf Sep 28 14:11:48 well, PACKAGES is defined by default, anyway Sep 28 14:11:59 among many other variables Sep 28 14:17:02 kergoth, rburton thank you, you have actually been very helpful today... this is useful info Sep 28 14:45:51 Hi all ! I have a little problem with yocto ... when I run the populate_sdk command, an sdk is been generated but doesn't contains the environment-setup file (error: ls: cannot access /home/f553218/CDR/sdk/sdk/environment-setup-*: No such file or directory). Sep 28 14:46:40 Does someone have an idea to resolve this problem ? Thank's in advance. Sep 28 14:47:10 I use, the meta-arago and meta-ti on my project. Sep 28 15:21:56 has anyone seen pseudo getting stuck in vsftpd preinst code, when installing it into 2 images at the same time? Sep 28 19:08:25 My Qt application has started to fail building when changing MACHINE (same TUNE). I get "cannot find /lib/libpthread.so.0" and "cannot find /usr/lib/libpthread_nonshared.a". However both MACHINEs sysroots does contain them. Sep 28 19:08:41 Am I missing a DEPENDS from my recipe perhaps? Sep 28 19:11:36 It works if I wipe the recipe and rebuild it. I had hoped to not set PACKAGE_ARCH="${MACHINE_ARCH}" as it would imply building the recipe twice. Sep 28 19:19:17 How do I DEPEND on libpthread.so in yocto? Sep 28 19:21:48 there's no need, the recipe that provides it is already in your depends by default unless you set INHIBIT_DEFAULT_DEPS Sep 28 19:23:40 I've recently seen a similar error in a build that didn't have ${base_libdir} in the linker search path Sep 28 19:24:02 (for reasons that were totally self-inflicted, but maybe the datapoint helps) Sep 28 19:25:24 kergoth: yes, I found that libpthreads.so is a part of glibc, and it certainly feels wrong to have to add that to depends or rdepends manually :o Sep 28 19:27:16 neverpanic, yes, thanks. This needs checking. Finding the linker paths in a Qt5 qmake generated makefile is very convoluted... Sep 28 19:29:04 is there a way to show/diff why a sstate cache missed? I suspect a non-needed env-var that prevents others from using the cache Sep 28 19:29:25 bitbake-diffsigs can do that, AFAIK Sep 28 19:29:36 thanks Sep 28 19:35:15 bitbake -S printdiff is easier, when you have enough bits in your sstate dir, anyway Sep 28 19:41:37 kergoth: great. I get something like "Task sp:do_compile couldn't be used from the cache because: We need hash ae42307751e7b1e7bf72eb29ecf632a7, closest matching task was 08937b42c48a26913aa8a263d89ef650. Taint (by forced/invalidated task) changed from nostamp:103aa7fc-9066-4cb6-9c8f-afd940da5ba6 to nostamp:ce74df30-f07a-4074-bb50-085feec5b258" Sep 28 19:42:03 If I understand this correctly, it's that taint I'm trying to pin down Sep 28 19:42:17 taint is use of -C or -f to force a task to run. cleaning and rebuilding it should remove the taint Sep 28 19:42:50 Does externalsrc set the taint? Sep 28 19:43:41 depends on your version. it used to mark its tasks as nostamp, as it wasn't tracking changes to files in the external source, so it couldn't know when to rebuild Sep 28 19:43:51 nowadays it checksums the entirety of the external source tree, iirc Sep 28 19:44:37 because this recipe use externalsrc (because the hg support in yocto does not work) Sep 28 19:45:46 as i said, old versions of externalsrc/bitbake will mark the tasks as nostamp, so they'll always re-run / always build from scratch Sep 28 19:46:32 kergoth: ok, then there might be something there worth checking. It might well be src leakage that changes/puts some intermediary into the source tree. Has happened before. Sep 28 19:46:43 kergoth: how old, do you know? Sep 28 19:46:55 not offhand, i'd check externalsrc.bbclass. see if it uses nostamp Sep 28 19:47:02 This version is somewhere between jethro and krogoth iirc Sep 28 19:47:20 i'm guessing that'ss probably far enough that it used nostamp, hence the taint, but definitely check Sep 28 19:47:29 thanks Sep 28 19:47:39 you could certainly look into alternatives to externalsrc, if need be Sep 28 19:47:55 no, we'll migrate to git when times come Sep 28 19:48:09 ah Sep 28 19:48:12 so we'll live with it if that is the cause Sep 28 19:49:28 jup, externalsrc.bbclass use nostamp. Then that it then. All right Sep 28 19:53:26 Is there a place inside bitbake where I could get the taskhash for a given task? Sep 28 19:55:11 it's all available in the cache, could probably add a debug write/print to cooker/cookerdata/cache somewhere Sep 28 19:55:19 bitbake does set a variable with it, but onlyw hile the task is running Sep 28 19:55:32 alternatively, just look at the name of its stamp file or sstate archive Sep 28 19:56:26 I'm looking for a non-hacky way to do this, so cooker/cookerdata/cache would be the way to go then Sep 28 19:56:50 Ideally, I'd just make it available in a variable, like BB_TASKDEPDATA Sep 28 19:57:58 there are a number of options. could create a standalone script to do it fairly easily, i imagine Sep 28 19:58:53 Ugh, not easy to debug linker commands when they are this long: https://bpaste.net/show/f795cb13599f Sep 28 20:00:05 nah, I'd need the data in a fairly central part of bitbake-worker, so I doubt "external script" is the way to go Sep 28 20:01:10 maybe everyone else knows, but i'd never tried this before for premirrors, but it works great: Sep 28 20:01:11 PREMIRRORS_append = " \ Sep 28 20:01:11 .*://.*/.* file://${LAYERDIR}/downloads/ \n \ Sep 28 20:01:11 git://.*/.* git://${LAYERDIR}/git/MIRRORNAME;protocol=file \n \ Sep 28 20:01:11 " Sep 28 20:01:24 I have a layer with a downloads and a git dir.. Sep 28 20:01:42 (the .*://.*/.* is the 'new' piece, before I explicity listed git://, http://, etc..) Sep 28 20:02:13 ah, doing that in layer.conf? Sep 28 20:02:14 nice the regex seems to be working on the proto field Sep 28 20:02:17 ya.. Sep 28 20:02:23 would ahve to, since LAYERDIR has no meaning anywhere else.. :) Sep 28 20:02:23 I'm constructing what we call 'download layers' Sep 28 20:02:24 cool Sep 28 20:02:33 BBFILE_COLLECTIONS += "oe-core-dl" Sep 28 20:02:33 BBFILE_PATTERN_oe-core-dl = "" Sep 28 20:02:38 LAYERVERSION_oe-core-dl = "1" Sep 28 20:02:43 and the premirror I just posted Sep 28 20:02:53 maybe i should handle ours that way. we don't have download layers, but we have shipped sources for a layer with the layer before, to avoid conflicts with the way our installer works Sep 28 20:03:03 cleaner than gather up the layer paths after the fact Sep 28 20:03:06 then in my openembedded-core, I can do LAYERRECOMMENDS_core = 'oe-core-dl' Sep 28 20:03:16 course it'd require modification of every layer for me to do it that way. Sep 28 20:03:18 nice Sep 28 20:03:48 the if a user selects openembedded-core, teh system will detect the recommend and install the oe-core-dl layer as well.. Sep 28 20:03:54 are you going to Berlin? Sep 28 20:03:55 fray, is that a first step at some kind of cm/repo managment? Sep 28 20:04:48 we've got a system we will be showing in berlin/ELC-E (with every intention to open source) that will use the layerindex to gather what you need for your project setup and download everything... this constructs a repo 'default.xml' file based on the layerindex contents Sep 28 20:05:03 so you can just do 'repo sync' to update.. or re-run the tool to download more stuff or change the project config Sep 28 20:05:18 it also updates/writes a new bblayers.conf.sample and local.conf.sample that is tailored for your config Sep 28 20:05:38 fray., nice! We are in the middle of configuration management discussions internally as well, since yocto does not provide any policy for that Sep 28 20:05:55 tailored -- all of the selected layers are int he bblayers.conf.sample -- and the local.conf.sample will have all of the available machiens and distros listed in it for easy config Sep 28 20:06:26 sveinse, well we're doing this as part of our commercial Wind River Linux 9 product -- but we do intend to open source the tooling and if the community (OE or YP) is interested put it back there.. Sep 28 20:06:41 the work is based about various OEDAM and OEDEM discussions over the last few years Sep 28 20:07:02 fray: yeah, let's hope for the best Sep 28 20:07:04 (we havn't gone through our IP review yet, so I can't share the code yet.. but it's working internally) Sep 28 20:07:34 key thing though it uses the layer index (and like the toaster, can use multiple layers indexes, so you can have a commercial, community and/or internal connected) Sep 28 20:07:42 in my opinion this is lacking from yocto, so all the different vendors does this differently. When we support various hardwares and BSPs, it's, well, a mess to maintin Sep 28 20:08:04 requirements vary. i don't think this is something that can necessarily cover every use case with a single tool Sep 28 20:08:07 ya, I can't solve the mess of BSP layers and such -- but this is a first step to a unified "initial project setup" program Sep 28 20:08:13 kergoth, exactly Sep 28 20:08:50 all of the previous attempts I've seen of this is static scripts (or even static repo files) that setup a project and expect the user to modify them.. Sep 28 20:09:11 by using the layer index and generating everything based on dependencies, hopefully it unified the stuff with the toaster and bitbake-layer interfaces that already exist Sep 28 20:09:23 kergoth: no, I don't either, but as fray sais, step 1 is to get the project cloned and configured, comprising of x layers Sep 28 20:09:35 kergoth, are you going to ELC-E? Sep 28 20:09:58 mentor tends to just have a monolithic repo setup or mel install and then processes layer dependnecies when adding them to bblayers in our setup scripts. the fetching of deps is nice, though, i might try using that for my personal stuff when you release it Sep 28 20:10:10 sadly not this year. i need to get to one of these, i haven't been to either ELC in years :( Sep 28 20:11:02 Enea seems to be similar from what I've seen Sep 28 20:11:11 ... it seems --sysroot is properly set up in the linker, so there is no reason why it cannot find /lib/libpthread.so.0... Dang! Sep 28 20:11:28 we've also got an enhancement for repo (which I'm having problems submitting back, internal issue) that lets repo pull down bare repositories.. Sep 28 20:11:36 that is needed for these special 'dl-layers' Sep 28 20:12:48 if repo didn't insist on agreeing to an android license for contributions it would be a whole lot easier.. Sep 28 20:15:52 kergoth, there is also a little trick you can do with the DL_DIR and the collection name to self-organize the bits.. :) Sep 28 20:16:08 DL_DIR .= "/${@wrl_downloaddir(d) or ""}" Sep 28 20:16:08 def wrl_downloaddir(d): Sep 28 20:16:08 recipe = d.getVar("FILE", True) or "" Sep 28 20:16:08 for collection in (d.getVar("BBFILE_COLLECTIONS", True) or "").split(): Sep 28 20:16:08 pattern = (d.getVar("BBFILE_PATTERN_%s" % (collection), True) or "")[1:] Sep 28 20:16:09 if pattern and recipe.startswith(pattern): Sep 28 20:16:09 return collection Sep 28 20:16:10 return None Sep 28 20:16:23 i'd really like to see us move to per-recipe DL_DIRs, but with logic for global caching, so we use symlinks or hard links into a common store Sep 28 20:16:59 fray: we have similar logic, i think we should consider adding variables to the core with the layer path and layer name of the layer containing the current recipe Sep 28 20:17:24 would be nice.. in our case, we just wanted the collection name.. Sep 28 20:17:31 so we organize the downloads dir w/ collection name Sep 28 20:17:49 i was thinking break up the underlying DL_DIR by download checksum, to ensure there's never a conflict, then set up the per-recipe links for it to pull from in unpack Sep 28 20:18:02 would cause issues for cleanall, though :) Sep 28 20:21:24 ld tries to access /lib/libphread.so.0, which is a host leakage. But it does not if I wipe the sources and rebuild :o Sep 28 20:21:43 weird Sep 28 20:34:20 How can I debug linker leakages? Sep 28 20:35:48 A few years ago when I was working with ubuntu arm sysroots, I made a script which traversed the entire sysroot looking for linker script which had absolute references in them because they caused linker leakages. This symptom I'm having is smelling awfully similar Sep 28 20:36:15 However, I don't understand why I get them just by swapping MACHINE Sep 28 21:38:56 I found it, it was due to a -L reference to the old MACHINE's sysroot, which caused strange errors. Since the recipe is set to build for TUNE, it does not reconfigure, and hence it does not update its Makefiles. Sep 28 21:41:42 But that sounds equally dodgy to me: if changing MACHINE also changes its libs and include sysroot, isn't it then a real risk that a already built TUNE recipe might be erroneous? Sep 28 22:02:05 Dear All, Sep 28 22:02:33 Is there a way to set SHELL variable when executing recipie? Sep 28 22:02:56 for example SHELL=/bin/dash bitbake -v -c task ? Sep 28 22:03:28 I would like to test correctness of the task execution with both SHELL=/bin/bash and SHELL=/bin/dash Sep 28 22:03:31 Is it possible? Sep 28 22:28:19 Any idea? Sep 28 22:51:02 lukma1: do it in local.conf. Sep 28 22:51:14 well, that'd affect the buildsystems we run, but not our tasks Sep 28 22:51:30 hmm Sep 28 22:52:16 lukma1: pretty sure ross already posted a script to do that for you **** ENDING LOGGING AT Thu Sep 29 02:59:58 2016