**** BEGIN LOGGING AT Fri Jan 15 02:59:59 2016 Jan 15 08:37:27 good morning Jan 15 09:04:47 hi, I have deleted everything in build/deploy/images/ and now I get error messages when running "bitbake core-image-minimal": ERROR: Error: The image creation script '/opt/PHYTEC_BSPs/yocto_ti/build/tmp-glibc/work/phycore_am335x_1-phytec-linux-gnueabi/core-image-minimal/1.0-r0/temp/create_image.sdcard' returned 1: Jan 15 09:04:47 Creating filesystem with Boot partition 45056 KiB and RootFS 53248 KiB Jan 15 09:05:03 does someone has an idea how this can be fixed? Jan 15 09:07:43 hm, I think I need to rebuild barebox. Jan 15 09:15:09 mwarning: hi, in the "image" folder, there is a readme that says "do not delete files in this directory" => (if I am not wrong) I think you will have to do "bitbake -c clean core-image-minimal" as the content of this file indicates Jan 15 09:15:41 Mylene: ah, ok. thanks :) Jan 15 09:16:03 Mylene: +1 Jan 15 09:16:23 Mylene: after a few compiles the directory just becomes rather messy Jan 15 09:17:25 mwarning: bitbake -c rootfs -f Jan 15 09:31:24 mwarning: you are welcome. Yes, it's true, you can delete some files but not kernel/bootloard images (and not all the directory's content). You will find more information here : http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-build-tmp-deploy-images Jan 15 09:31:51 ok, thanks Jan 15 09:33:57 one last question (for now :P), how do I change the filesystem type for the rootfs of the sdcard image? Jan 15 09:34:22 in build/config/local.conf? Jan 15 09:41:24 when I set IMAGE_FSTYPES += "ext3 sdcard" there, I have the ext3 and ext4 rootf files created, but I wonder what is one on the sdcard image. Jan 15 10:30:06 'DEPENDS +=' in a bbclass wouldn't be safe in case it's inherited before the DEPENDS assignment in the bb file, right? i know that isn't the standard order either way. Jan 15 10:30:42 the poky bbclasses aren't consistent there Jan 15 10:38:58 HI I'm facing this error Jan 15 10:39:00 ERROR: QA Issue: mosquitto: Files/directories were installed but not shipped in any package: /usr /usr/local /usr/local/sbin /usr/local/li Jan 15 10:39:28 How do I add /usr/local/sbin/ to FILES Jan 15 12:38:04 joshuagl: : Recipient address rejected: undeliverable Jan 15 12:38:07 address: User unknown in virtual alias table (in reply to RCPT TO command) Jan 15 12:38:31 that's his old work address. Jan 15 12:38:57 he was still using it 16 Dec 2015 20:43:06 +0000 Jan 15 12:39:18 do we need new Fido maintainer with stable e-mail address? Jan 15 12:40:08 fwiw I've found his gmail address Jan 15 12:43:31 he was still at collabora then :) Jan 15 12:43:39 kergoth: figured it out... ${S} was set to some subdirectory thereof, and all the files were there, but not off of that subdirectory Jan 15 12:44:33 I still do not understand how this build works at all on other systems Jan 15 12:45:55 Hi. I am currently building a Yocto for a boundary device (Nitrogen6X board) and I pretty much follow this example: https://boundarydevices.com/fido-release-of-yocto/ Jan 15 12:46:42 After dd the image to SD Card and booting, I check whether gcc and/or g++ is installed by typing g++ --version Jan 15 12:47:00 But it says gcc: command not found Jan 15 12:47:30 What do I have to do so development tools like gcc, g++, make ... are also built when creating the yocto-image? Jan 15 12:48:38 JaMa: the stable maintainer page should be up to date Jan 15 12:57:45 what is "the stable maintainer page"? https://wiki.yoctoproject.org/wiki/Releases doesn't show e-mails Jan 15 12:58:15 hmm https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Jan 15 13:16:09 DamBedEi: gcc is expected to run as a cross-compiler Jan 15 13:16:19 DamBedEi: on PC side Jan 15 13:16:35 JaMa: sorry, was mostly afk but looks like you've found it Jan 15 13:20:37 alright so bottom line: How do I absolutely unequivocally tell bit bake to rebuild a recipe from the ground up Jan 15 13:20:49 as in, re-do the fetch, unpack, compile, everything - how do I clean? Jan 15 13:21:12 I have tried bitbake -c clean recipe and bitbake -c cleansstate recipe with no luck! Jan 15 13:22:31 cleanall Jan 15 13:22:43 cleanall is like a nuke though right - that's every recipe? Jan 15 13:22:57 mckoan: ah, okay. Thanks Jan 15 13:23:01 no just cleansstate + cleaning the fetched sources Jan 15 13:23:14 is that on a per-recipe basis? Jan 15 13:23:18 y Jan 15 13:23:20 so bitbake -c cleanall recipe Jan 15 13:23:36 JaMa: Anything wrong with http://patchwork.openembedded.org/patch/111291/ and http://patchwork.openembedded.org/patch/111277/ ? Jan 15 13:24:07 and the talloc/... dependency fixes? Jan 15 13:24:34 ask Joe Jan 15 13:24:40 I've seen the latter one in master-next but disappeared and I don't know why and what is expected Jan 15 13:25:30 both are in master Jan 15 13:25:56 Ok, I probably should switch to glasses Jan 15 13:26:36 there are many pending meta-networking patches waiting for Joe, but these 2 aren't part of that Jan 15 13:26:50 I found them and found why I was mislead Jan 15 13:27:16 fd66e4713 was in master before X-Mas and I searched for samba and hit that Jan 15 13:27:35 hitting 'n' enlightend me :( Jan 15 13:52:33 Hi. Can some help me with mosquitto mqtt recipe Jan 15 13:52:48 I couldn't find any latest version Jan 15 13:53:13 >1.4 Jan 15 15:26:56 hodapp: that was exactly what i told you it was probably doing.. but i'm glad you figured that out :) Jan 15 15:26:59 oof, need more caffeine Jan 15 15:35:08 kergoth: I know that feeling Jan 15 15:43:50 kergoth: well, a subdir of the sources would have been fine if it actually led someplace :P Jan 15 15:44:12 at some point I realized that 'patch' doesn't like patches with ../ in them Jan 15 15:45:02 guess I should submit a patch to Intel or something Jan 15 15:45:05 the patch task will obey a subdir= parameter in the patch file url Jan 15 15:45:11 to get it to apply it elsehwere in teh source tree Jan 15 15:45:19 ;subdir=.. or similar should do Jan 15 15:48:20 ah, I just did this with SRC_URI Jan 15 16:58:53 Hello there! Quick question: how do I use core-image-minimal-initramfs ? Jan 15 16:59:48 after building the image, I run "runqemu qemux86-64 core-image-minimal-initramfs ramfs" but all I get is "Cannot find rootfs.img file in /run/media/* , dropping to a shell" Jan 15 17:00:17 I am trying to run a diskless qemu instance, btw Jan 15 17:18:50 * armpit hmm layer index not indexing Jan 15 19:51:35 hi guys Jan 15 19:51:48 I have an issue with a bbappend with wildcard Jan 15 19:51:55 like described here: https://lists.yoctoproject.org/pipermail/yocto/2014-November/022395.html Jan 15 19:52:22 meaning, when I have a bbappend with a wildcard it does not work as expected Jan 15 19:54:53 so the wildcarded bbappend in a higher priority layer gets processed earlier that another non-wildcarded bbappend in a lower priority layer Jan 15 19:55:20 and the changes in the wildcarded bbappend are not propagated as expected Jan 15 19:55:24 anybody seen this before? Jan 15 19:58:13 manderke: if you're not on the latest release, you might need 3cb87724a5b21550e99c18e97b665d6604bb2fa9 in poky, which is f980f060cd0d1e7fe5011f3c325c1b254f05eccf in bitbake, which fixed an issue with non-deterministic ordering between % and non-% appends Jan 15 20:09:52 Does anyone recall why we have multiple variables (SDKTARGETSYSROOT, OECORE_TARGET_SYSROOT) in the sdk env setuip script which refer to the same path? Jan 15 20:10:19 sec.. Jan 15 20:12:31 I'm blanking.. Jan 15 20:12:44 I do remember there was a difference and there (at one point) was a reason they could change.. Jan 15 20:12:49 but I'm not longer remembering what it was Jan 15 20:13:04 (it's also entirely possible that the initial reason is no longer valid either) Jan 15 20:13:09 hmm, k Jan 15 20:13:15 figured it'd be worth consolidating Jan 15 20:13:31 but i'd hate to break environment-setup.d scripts Jan 15 20:14:22 ya I just looked and I don't see any difference in meta-mingw either.. Jan 15 20:14:38 so I suspect the rationale might only be by looking back at the older code.. and it's likely no longer valid Jan 15 20:14:50 kergoth, thanks Jan 15 20:15:20 Thoughts on having the env setup script find the paths relative to its own location, and only if it can't do that (i.e. non-bash/non-zsh) fall back to the hardcoded paths? I'd like to slowly reduce the reliance upon relocation scripts Jan 15 20:15:27 manderke: np Jan 15 20:16:14 the relocation script isn't because of the environment script, it's because of the executables themselves.. at least on Linux they need to know which ld.so to laod -- so that has to be programmed into them via the script.. Jan 15 20:16:35 On the mingw SDK we have, we do dynamically find the execution path -- since tehre is no necessary relocation... Jan 15 20:16:42 Yeah, I know, but it ends up altering that too as a part of the grep+sed Jan 15 20:16:44 afaik anyway Jan 15 20:17:08 yes.. it touches all of the files.. I don't see a reason the 'guess' at the runtime location in the environment, if the others end up having to be hardcoded.. Jan 15 20:17:18 if there was some way to make theothers dynamic, then I'd say it all becomes dynamic.. Jan 15 20:17:38 It's not really guessing, it's deterministic, using the info zsh and bash provide about the script being sourced Jan 15 20:17:52 but that's fair enough, perhaps i'll shove it onto a branch to gather such improvements over time Jan 15 20:18:14 i.e. i also have patches to automake/autoconf/libtool to make them relocatable Jan 15 20:18:15 (on mingw we use: echo 'set SDKROOT=%~sdp0%' >> $script .. for those of you not versed in MS bat file syntax.. basically says give me the short path of whereever this file is executed from) Jan 15 20:18:22 but alone that's not terrible useful Jan 15 20:18:34 people do crazy things w/ symlinks and such and expect it to work.. Jan 15 20:19:15 before we did OE, we had some issue with similar code when people would do that and expect it to work.. with the (current) OE way of doing things, they can link all they want and they do get the right end result (with the cost of not being able to 'mv' the installed dir) Jan 15 20:19:50 I wonder if it'd be worth looking at application namespaces at some point to try to avoid relocation issues for linux. just mount the install in a deterministic location in the namespace of anything we run from it, or something Jan 15 20:20:11 not sure Jan 15 20:20:16 kergoth, any chance this commit might be backported to older releases? Jan 15 20:20:35 manderke: probably, you can request it be backported by emailing the stable release maintainer(s) Jan 15 20:20:57 I see, thought there may be some technical issue with it being backported Jan 15 20:21:15 that was a pretty clear bug that caused non-deterministic behavior due to things like SRC_URI order changing, breaking patch application, or at the very least causing checksums to change from time to time depending on the order Jan 15 20:21:33 so i doubt there'd be too much objection, but it'd be up to the maintainers Jan 15 20:22:21 cool, thanks again for support Jan 15 20:45:39 we have a case where we're distributing the sdk via a different mechanism, so the relocation script isn't run at install time, so i patched the setup script to get its own location and then run the relocation script on the first source of the env setup script with that location :) Jan 15 20:49:30 if it gets "moved", can the relocation script be run again (with success?) Jan 15 20:50:38 maybe? I don't remember how naive the logic is :) Jan 15 20:51:54 yeah such a 'fixup' feature would be desirable Jan 15 20:52:37 ya, I wouldn't be against a (non .sh) install, where th first time you run an environment script it relocates, and subsequent times it "checks".. only downside is 'read-only' installs.. Jan 15 21:12:44 kergoth: re: namespaces: we're actually doing that; we ship an SDK with a small tool that drops users in a mount namespace that looks like the target image + some native tools in /opt/nativesysroot; that allows us to transparently cross-compile because /usr/bin/gcc is a cross-compiler for the target architecture Jan 15 21:13:07 of course that requires that you can actually run target-architecture binaries on your SDK machine, either because it's x86 or using qemu Jan 15 21:13:37 but that completely avoids the need for relocation scripts (or installing at all) Jan 15 21:13:37 yeah, and it means you can't run the build machine compiler to build native tools for the crosscompilation,b ut that's similar to what i'm thinking, just with a different intention Jan 15 21:13:39 cool Jan 15 21:13:42 * kergoth nods Jan 15 21:14:37 Yes, we tried to make this as easy as possible for developers, but one could also keep gcc as host compiler and ship cross compilers separately Jan 15 21:14:56 Now if we only could get some time reserved to actually show you that stuff… Jan 15 22:32:22 i want to make this image http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/machines/genericx86-64/core-image-sato-dev-genericx86-64.hddimg Jan 15 22:32:59 it is made from http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/machines/genericx86-64/genericx86-64-jethro-14.0.0.tar.bz2? Jan 15 22:33:07 ? Jan 15 22:34:37 or how can create this image from source Jan 15 22:45:34 SyntaxError: Non-ASCII character '\xc3' in file /opt/genericx86-64-jethro-14.0.0/bitbake/lib/bb/pysh/pyshtables.py on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details Jan 15 22:45:38 any help Jan 15 22:45:48 it occurs when i want to toaster Jan 15 22:55:00 I'd be curious about how that character go tinto that file in the first place, pyshtables is generated by pysh Jan 15 22:55:15 *if* it's valid for pysh to be emitting that, then it needs to write an encoding line into the file Jan 15 22:56:32 how can solve it Jan 15 22:57:57 manually adding '# -*- coding: utf-8 -*-' line to the top of the file might work Jan 15 22:58:02 don't know for sure Jan 15 22:58:08 let me try Jan 15 22:59:57 i solved Jan 15 23:00:28 i think it should be fix about encoding Jan 15 23:01:02 first i extract bitbake a nonencoding directory for my locale Jan 15 23:01:20 it errored first Jan 15 23:01:26 so imoved it /opt Jan 15 23:01:32 i moved* Jan 15 23:01:49 but pyshtables.py autogenerated file Jan 15 23:02:17 so it created in my first onencoding directort Jan 15 23:02:18 y Jan 15 23:02:39 so it includes nonencoding path info. Jan 15 23:03:05 ah, i see, that makes sense Jan 15 23:03:15 you should open a bug in the yocto bugzilla for that Jan 15 23:03:43 ok Jan 16 00:01:41 Cloning into '/opt/genericx86-64-jethro-14.0.0/bitbake/bin/_toaster_clones/_remote_origin_jethro'... Jan 16 00:01:42 ssh: Could not resolve hostname remote: Name or service not known Jan 16 00:01:54 when i want to compile a recipe Jan 16 00:02:10 background of toaster occurs it Jan 16 00:17:37 ./bitbake/bin/bitbake Jan 16 00:17:37 The BBPATH variable is not set and bitbake did not find a conf/bblayers.conf file in the expected location. Jan 16 00:17:37 ? Jan 16 01:15:04 OperationalError: attempt to write a readonly database Jan 16 01:36:54 http://paste.debian.net/366093/ Jan 16 01:36:58 any help? **** ENDING LOGGING AT Sat Jan 16 02:59:58 2016