**** BEGIN LOGGING AT Tue Aug 15 03:00:02 2017 Aug 15 05:46:46 RP: I have created a pull request for binutils/gcc upgrade here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu Aug 15 05:47:04 RP: these patches are posted to ml too. Give it a shot on AB Aug 15 07:34:25 khem: doing my best, struggling to merge anything at the moment due to tracking down failures :( Aug 15 10:16:06 halstead: the cluster is falling apart, first build looked ok, second one is just causing infrastructure collapse :( Aug 15 10:16:19 * RP tries the other AB Aug 15 10:39:22 TafThorne: `inherit autotools pkgconfig` does not solve the issue with the missing headers of libbsd. Is it possible that in general headers are not installed by default? do I have to append sth. to the recipe to get the headers installed? Aug 15 10:54:02 anyone else has some issues with grub keystatus module? Aug 15 12:26:18 TafThorne: I think I lacked some basic understanding. the header files are installed to sysroot if I use `bitbake my-image -c populate_sdk` and execute the corresponding toolchain installer script. Aug 15 12:27:28 the headers are not installed to fs of the image itself. Aug 15 12:27:45 so everything seems to be fine, thank you Aug 15 12:35:14 I know this has been asked before, but I can't recall if someone had a good answer to it.. Is it possible to tell bitbake not to do the fancy carriage-returns where the terminal output lines are rewritten and just get a scrolling text with all the output? Aug 15 12:36:03 Which would mean omitting the fancy progress meter and the rest of it.. Aug 15 12:38:49 Nevermind .. it does some detection of stdout, so just piping it to cat does the business. Aug 15 14:42:39 brrm: I am glad you got things sorted out and understood what was causing the things you were observing. Loose ends and unexplained behaviour can be a pain. Aug 15 15:18:15 RP: no worries, my world builds for all qemus with gcc 7.3 and binutils 2.29 came out clean now running with musl Aug 15 15:18:35 RP: i dont expect any issues in general since its mostly bug fix release Aug 15 15:40:31 khem: right, binutils is looking ok, will add gcc into the mix when I ca Aug 15 15:40:33 can Aug 15 15:51:47 Hi. I'm a noob in need of help. I'm trying to run bitbake for an iMX53 on Ubuntu 16.04. It fails with compile errors. I've seen posts indicating Ubuntu 14 might be required? Aug 15 15:51:48 ok Aug 15 15:54:24 buvinj: what errors do you see. Secondly which release of YP are you using Aug 15 15:54:58 if its an old YP release it might not work with ubuntu 16.04 Aug 15 15:55:42 invert_limb.o: relocation R_X86_64_PC32 against protected symbol `__gmpn_invert_limb_table' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make[2]: *** [libgmp.la] Error 1 Aug 15 15:55:52 That's the most current Aug 15 15:55:53 look into meta-yocto/conf/distro/poky.conf SANITY_TESTED_DISTROS lists the validated host distros Aug 15 15:56:41 I get a warning when I run bitbake saying the Ubuntu 16.04 is not tested Aug 15 15:56:56 buvinj: its possible, since newer ubuntu switched to PIE as default and it might not be compiling some of host packages as expected Aug 15 15:57:01 ok Aug 15 15:57:05 there you go then Aug 15 15:57:13 I read that in theory changing to an old gcc could work Aug 15 15:57:29 I would suggest to use one of SANITY_TESTED_DISTROS Aug 15 15:58:17 So there is no good solution generally speaking other than to run a whole other OS? Aug 15 15:58:20 mix and match and you are treading your own path. Decide where you want to spend your efforts Aug 15 15:59:02 I would suggest to use VM or container Aug 15 15:59:13 or use newer Yocto release Aug 15 15:59:18 which works on 16.04 Aug 15 16:00:39 Hmm. How do I use a newer Yocto release? I ran a command to clone the source for iMX53, am I not locked into whatever is the repo? Aug 15 16:01:08 I've never used Yocto or bitbake... Aug 15 16:01:43 Being dependant on an old OS is a terrible situation Aug 15 16:02:06 Linux distros go eol, and all the packages dry up for them Aug 15 16:02:33 It's not a viable plan for something you need for years to come Aug 15 16:03:21 I was previously screwed by that exact situation involving a project I inherited for an old AOSP build Aug 15 16:05:50 This is what I execute to clone the repo: sources/b2qt-yocto-meta/b2qt-init-build-env imx53qsb-eLinux Aug 15 16:07:53 This is a boot2qt image I'm ultimately looking to build. They offer partial support for the iMX53 currently, but you have to build your own image, and they don't provide the documentation! Aug 15 16:10:03 Is there a reasonable way I might tweak that repo to use the current Yocto release? Aug 15 16:20:35 yes, with VMs and build appliances you can capture the build environements easiliy now a dya s Aug 15 16:21:19 eveything is fixable. Its just you have to find what you want to do Aug 15 17:09:39 Hey guys, looking for some advice. Given a working image, I then want to deploy that to multiple hosts. Each host will need specific config info [primarily network hostname]. Does anyone have a slick approach to this problem? Any questions or comments appreciated./ Aug 15 17:29:38 majuk, there is a section of the manual on customizing hostname at build time ( https://www.yoctoproject.org/docs/2.0.2/mega-manual/mega-manual.html#usingpoky-extend-customimage-image-name ) but it sounds like you want to change /etc/hostname after installing the image? Aug 15 17:54:11 hackrack: Yes, that's correct. Aug 15 17:54:37 Basically, if I have 100 clients, I don't want 100 individual images that I have to hang on to Aug 15 17:55:03 I think I have a viable way forward, but I was curious how anyone else might have addressed the issue. Aug 15 17:56:05 I'd expect the easiest method would be to create a recipe with a service that arranges things on first boot based on some identifier, i.e. the ethernet mac. alternatively, modify the image after the fact when you're deploying it Aug 15 17:59:01 The way I do it for embedded systems is to use a read only root to avoid bricking the device. Then there is a writable "data" partition. Under that partition you could put a "hostname" file and then you bind mount /etc/hostname to /data/hostname. Then you can just modify the file on the data partition. Aug 15 17:59:29 Oooo, that's solid, I hadn't thought of segmenting the file system like that. Aug 15 18:00:52 Yea, a lot to consider. Thanks for y'alls input. Aug 15 18:02:05 that's true, using a read only rootfs with a writable user data partition is actually a great approach regardless of customization per-device, means you can also use different update deployment mechanisms, i.e. swupdate with dual-rootfs and fallback on errors, without hosing the user's data Aug 15 19:59:33 any clues why i'm getting this error? https://da.gd/npQd -> https://paste.fedoraproject.org/paste/YGaj~OCKf6K7gkWmbb75SA/ Aug 15 20:00:14 this is from a devtool build-image that was executed after a devtool modify -x followed by some .dtsi mods. Aug 15 20:00:40 and it built (bitbake ) just before this Aug 15 20:13:14 TafThorne: any ideas? Aug 15 20:22:00 if i had modified some sources after a "devtool modify -x recipe-kernel", would a subsequent "bitbake recipe.image" overwrite my source file changes? Aug 15 20:22:18 Can somebody help me ...... Aug 15 20:22:55 lukma: yes, what do you need? Aug 15 20:23:06 why when I define EXTRA_IMAGE_FEATURES = "debug-tweaks dbg-pkgs dev-pkgs tools-debug" Aug 15 20:23:22 in my /conf/local.conf Aug 15 20:23:40 my buildbake core-image-xxx builds image with .debug included Aug 15 20:24:18 but it is not done when I add the same line in my /conf/distro/board.conf ? Aug 15 20:24:55 in the second case the bitbake -e | grep ^EXTRA_IMAGE_FEATURES shows correct (and expected values) Aug 15 21:08:26 if i do a "devtool modify -x recipe-kernel", will a "bitbake recipe-image" then build the same as if i had done a a normal (non-devtool) "bitbake recipe-image" from the git-go? Aug 15 21:12:40 I don't understand the question. of course not, it'll be building from your workspace sources that were set up when you did the devtool modify, rather than fetching from upstream Aug 15 21:12:45 which the whole point to devtool modify.. Aug 15 21:30:10 kergoth: i am trying to ask if the two approaches will generate the same results if there were no in-tree mods after the devtool modify -x . Aug 15 21:30:32 yes, if not there'd be no point Aug 15 21:30:59 the whole purpose of devtool modify is to let you do active development, if it didn't give you the exact same source tree as would be used otherwise, it'd be of no use Aug 15 21:31:34 now, if the recipe changed after devtool modify, such that the source trees are out of sync, then the answer would likely be no, unless it was updated iwth devtool Aug 15 21:32:15 i am getting an error in a devtool build, but not in my normal build, even thought i think i've backed out the changes i made. Aug 15 21:33:03 i may just have to start a new build workspace. Aug 15 21:33:14 no biggie - i can wait another hour+ to rebuild.. Aug 15 21:33:41 there was only one file i changed, and i have a copy of it in my home dir. Aug 15 21:33:51 (should have changed) Aug 15 21:42:45 is there a way to specify "default" build/conf/bblayers.conf and build/conf/local.conf files in a layer? perhaps under the layer's conf? Aug 15 21:44:35 or is there an argument to the oe-init-build-env to do this? Aug 15 22:03:06 anyone here knows who's working on rock64 yocto support ? **** ENDING LOGGING AT Wed Aug 16 03:00:00 2017