**** BEGIN LOGGING AT Mon May 23 02:59:58 2016 May 23 07:33:30 good morning May 23 08:10:55 Hi guys! :) May 23 09:00:54 Hi! Any ideas what to do when yocto builds repeatedly are running out of memory? Stats somewhere? Abusers/bad recipes somewhere? Limits not correctly set? May 23 09:41:57 Hi. How do I build nightlies with yocto May 23 09:42:38 I create a default.xml manifest for using it with repo tool May 23 09:43:07 I want all the build procedure to be automated starting from 'repo init', 'repo sync' May 23 09:43:35 Is it possible with auto-builder or should I use my own buildbot May 23 09:45:15 yocto-autobuilder is basically a custom buildbot, and you can probably configure it to trigger automatically. depends on what you want, really. i used to just have a ten line shell script in cron as all i wanted was a local sstate populated. if you want to deploy stuff, then something more complex like yocto-autobuilder has some functionality implemented for you. May 23 09:47:59 or, have some jenkins instance automate it May 23 09:48:13 e.g. "depends on what you already have, and what you need." May 23 09:51:11 yeah May 23 09:53:45 and as most people tend to have a custom project setup infrastructure of one way or the other, that is what you shoudl feed your build infrastructure. May 23 09:54:36 so if you're using repo, make your build automation call repo to set up everything, and then kick off the build. May 23 10:07:32 @rburton @LetoThe2nd I've created my own buildbot now with this factory --> http://pastebin.com/cqJL28kJ May 23 10:07:43 I'm new to both buildbot and yocto May 23 10:08:22 My 'source export' command is some how failing from buildbot but working when I do it manually May 23 10:09:06 I asked this at the end of last week so sorry for repeating, can .bblayers handle include files? May 23 10:10:16 CTtpollard: probably... did you try it ? May 23 10:10:42 boucman_work: heh yeh, can't tell if I've messed up though or it genuinely can't handle it, will keep on tweaking May 23 10:11:50 CTtpollard: check the bitbake user-manual... at this point it's not really yocto yet. May 23 10:12:14 the path in which includes can be found is also probably VERY limited. you might have to add it into a variable in the bblayers.conf May 23 10:13:20 boucman_work: the order of the bblayers in the list doesn't have any affect right? it's the individual layers priority value that defines that right? May 23 10:13:44 not sure... again the bitbake refmanual is your friend May 23 10:13:57 (it's not part of the yocto doc bundle) May 23 10:14:01 here is my log --> http://pastebin.com/MAhk8uaz May 23 10:14:15 Could some one help me with that pls May 23 10:28:37 anyone know if you can BBLAYERS_$MACHINE += or something similar? May 23 10:29:56 CTtpollard: you can't do that, no May 23 10:30:12 CTtpollard: when bblayers is read, MACHINE doesn't exist yet May 23 10:30:23 it's part of local.conf which comes way later May 23 10:30:49 basically a yocto build directory == a fixed set of layers May 23 10:30:56 boucman_work, bluelightning: thanks, was thinking it would be cleaner for multiple targs than trying to use.inc across multiple templates May 23 10:31:07 (but you can have multiple build dirs sharing downloads and sstate) May 23 10:31:36 CTtpollard: in case it is relevant, BSP layer best practice is to not have any effect when MACHINE isn't set to match the machine(s) supported by the layer May 23 10:31:53 CTtpollard: it's usually ok to include all that's needed for all targets... the meta from a target shouldn't pollute the meta for another, if they are made correctly May 23 10:32:05 CTtpollard: i.e. everything the layer does should be conditional on the machine May 23 10:38:48 CTtpollard: meta-renesas does not conform to that rule 100% May 23 10:39:14 for example, its own weston_1.5.0.bb recipe is not conditional on a specific machine May 23 10:40:09 yeah... meta from board builders are not as clean as the official ones May 23 10:40:11 I have been working around this with an ugly BBMASK .= "bb.utils.conditional ..... " monster May 23 10:40:42 and don't start me on the horrors you have on how to use yocto with some board-makers that repack stuff done by other board makers :( May 23 10:41:24 boucman_work: such as bb.conditionals? ^^ May 23 10:41:27 :) May 23 10:41:36 if only May 23 10:41:56 the latest one I have been using has the following step to use their board May 23 10:42:46 1) rebuild a complete yocto image using the toradex image (which is based on angstrom with their own layer that is heavily dependant on angstrom) May 23 10:42:56 then download a cross toolchain from somewhere May 23 10:43:02 then recompile your own kernel May 23 10:43:26 then modify the rootfs to add whatever tool they want you to add May 23 10:43:32 then recreate a sdcard from that May 23 10:43:47 May 23 10:44:04 I mean... did they even look at yocto at all ??? May 23 10:44:55 niiiiice May 23 10:46:17 yeah... real life May 23 10:47:11 that's why i'd love to see a yocto-sepcific repo tool of some sort. each board dev has its own tool, none of which are really good. I really think that having an official one would cleanup that mess by having people standardize May 23 10:47:27 even if the tool itself is not that good, having a single tool would be a huge progress May 23 11:42:56 boucman_work, you mean lite Toaster? May 23 11:43:00 *like May 23 11:43:38 boucman_work, on top of bitbake, with repo you don't need really more tools right? May 23 11:44:27 #!/bin/sh May 23 11:44:27 # Set the TEMPLATECONF variable inside the ./poky/.templateconf file May 23 11:44:27 # to retrieve meta-lightpixels configuration files: May 23 11:44:27 echo "TEMPLATECONF=$PWD/meta-lightpixels/conf" > ./poky/.templateconf May 23 11:44:27 # Source the actual OpenEmbedded script: May 23 11:44:28 . ./poky/oe-init-build-env May 23 11:44:30 My tool :P May 23 11:44:41 Nothing more needed ;) May 23 11:44:55 present: no toaster is a GUI, not really my use case May 23 11:45:02 repo is almost there, but not quite... May 23 11:45:11 it is :) May 23 11:46:35 Toaster is a nightmare for me. I can't get through any single error. As soon as it crashed I'm done. May 23 11:48:21 I did not like the huge script on top of oe-init-build-env that freescale is using. May 23 11:48:58 Just the strict minimum. Update .templateconf each time. May 23 11:49:26 Toaster is a nightmare for us all … ;) May 23 11:52:01 By the way I proposed a patch on psplash to get the --fbdev option. Someone around than can have a look? :D May 23 11:52:07 *who May 23 12:54:37 Hello, I'm using mercurial as a source revision system for my custom module and I'm having issues getting yocto to pull a new version from hg (using jethro, i.e. bitbake 1.28.0) May 23 12:54:49 My error is: | ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 255, output: | abort: unknown revision 'f7eb1171af28'! May 23 12:55:34 however, this revision exists in my hg repo... it appears yocto does not try to re-pull the repo, it just checks agains the last pulled hg version May 23 12:56:01 A workaround is to do a bitbake -c clean my_module and then to the build but this is a bit annoying May 23 12:56:16 Could this be a bug or am I doing something wrong? May 23 12:57:18 this is essentially my entire config: May 23 12:57:18 SRC_URI = "hg://build_user@local_hg_server://var/systems/mercurial;module=my_module;rev=${SRCREV};protocol=ssh" May 23 13:01:48 gardarh: sounds like a bug in the hg fetcher, not many people use it May 23 13:03:06 Hi, we are creating SDKs with poky for a number of ARM-based machines. I suspect that the GCC toolchain in each of them is essentially the same and would like to create a separate installation for 'package' for the GCC toolchain. Can this be done? Where do I direct my question? May 23 13:04:14 rburton: Thanks, so I'm guessing my solution would be to fix the bug and upload a patch? May 23 13:05:53 gardarh: please! May 23 13:06:20 sigh :) May 23 13:07:02 i traced down a problem with fetching different SRCREVs from the same svn repo (and perhaps module) concurrently. turns out the lock file used by bitbake includes the SRCREV in its name, and so does not protect the shared ${DL_DIR}/svn/... checkout properly. May 23 13:07:22 it's because of this line in svn.py: ud.localfile = data.expand('%s_%s_%s_.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.path.replace('/', '.')), d) May 23 13:07:38 do you know why the revision is included? May 23 13:07:50 urr May 23 13:07:55 sorry, that was the fixed line :P May 23 13:08:01 ud.localfile = data.expand('%s_%s_%s_%s_.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.path.replace('/', '.'), ud.revision), d May 23 13:08:04 i mean May 23 13:08:07 +) May 23 13:10:13 it's a really easy problem to reproduce btw: have two recipes foo.bb and bar.bb fetch different revisions from the same non-tiny svn repository and run 'bitbake foo bar'. the fetch will fail with a lock-related error from svn. May 23 13:12:07 Ulfalizer: doesn't that determine the name of the output file? I think it would make sense that it contains the revision number. May 23 13:12:47 yeah, determines the name of the tar.gz file, which in turn determines the name of the lockfile May 23 13:13:19 i don't even know where it's used though. there's already an unpacked version in ${DL_DIR}/svn. May 23 13:13:29 unless some PREMIRROR thingy uses it... May 23 13:15:34 yeah, the download cache only has the tarball May 23 13:16:01 so if the tar.gz file determines the name of the lockfile I think that's the bug May 23 13:16:26 also consider the case where the repository is the same, but the "module" changes to a different subdir May 23 13:24:41 what do you mean by download cache? the ${DL_DIR} cache has an svn/ directory with all the repos checked out in addition to the tarballs. are there more download caches i've missed? :/ May 23 13:26:00 yeah, having the module in the name of the lockfile makes sense. i think you get a separate .svn/ directory per module as well. May 23 13:32:35 Ulfalizer: the svn/ directory is only used to generate the tarballs, and the tarballs are what is used to extract the source code later on, I think May 23 13:33:05 so the svn/ directory is just temporary and not used after the tarball has been created (which makes sense, because the next fetch might re-use the checkout in svn/ and checkout a different revision) May 23 13:34:44 yeah, that might be how it works.. May 23 15:05:18 halstead: around? May 23 15:05:55 halstead: builds on centos7 are taking a very long time. I can ssh and it says 99% idle but its very very laggy borderline hanging. Any idea what's wrong with it? May 23 15:06:26 halstead: tempting to blame buildtools except that wouldn't cause it to be as laggy would it? May 23 15:07:05 RP, I'm just about to get started for the day. I'll take a look. May 23 15:16:10 halstead: it does appear to be running, just very slowly and it does seem stuck in python :/ May 23 15:17:36 halstead: dmesg shows hung tasks, tempted to suggest rebooting it as a first step... May 23 15:24:12 I may have to. I'm timing out waiting for an event list. May 23 15:28:38 RP, Perhaps selinux violations have overrun the auditlog. May 23 15:30:32 halstead: could well be and then the ratelimiting is crippling it? May 23 15:32:18 RP I'm not sure. I hope I can find out after a reboot. May 23 15:33:48 hello everyone\ May 23 15:34:12 anyone knows how can i add sudo and apt-get to my core-image-minimal , in which recipes they exist May 23 15:34:47 also ,i would like to know how can i have a file system that looks like ubuntu , i mean , it will have the same directories structure May 23 15:35:20 hello May 23 15:35:28 rburton, I sent the patches for psplash. :) May 23 15:36:23 I should have kept exactly the same commit log title because it was on two repositories. But with fbdev we can find it. May 23 15:50:39 morning May 23 16:16:51 RP, I've increased the audit buffer 20x and set the system to discard messages if it gets overwhelmed. May 23 16:17:01 RP, Now to run another build and watch. May 23 16:18:52 halstead: we can run the jethro release build May 23 16:19:56 RP, Alright. Shall I start it? Also so many tests have left us low on disk space. May 23 16:21:04 RP, I need to remove some nightlys from http://autobuilder.yoctoproject.org/pub/nightly/ May 23 16:21:57 RP, Anything important should be in http://autobuilder.yoctoproject.org/pub/releases/ so I'll just remove a few of the older nightly builds unless you need them. May 23 16:24:17 halstead: we just need the fido release build in QA atm May 23 16:24:23 halstead: everything else can go May 23 16:24:30 * halstead nods. May 23 16:24:45 halstead: let me check all the versions are right for jethro May 23 16:25:34 halstead: ba-bump pushed. All ready for a jethro build :) May 23 16:27:32 RP, Shall I start it now? May 23 16:29:33 halstead: please May 23 16:30:21 RP, Will do. Do we need the artifacts from this? May 23 16:30:37 halstead: yes, its going to QA as a release build May 23 16:31:01 halstead: I can trigger this if you don't know the right fields? May 23 16:31:16 I was going to ask pidge but she's not around May 23 16:32:02 RP, I know the fields but I wasn't clear on the goal. So is this a 2.0.2 RC? May 23 16:32:58 halstead: yes, 2.0.2-rc1 May 23 16:33:11 Alright. Got it. May 23 16:33:48 halstead: actually, please wait May 23 16:33:59 Will do. May 23 16:33:59 halstead: I don't have the branches set up correctly :( May 23 16:35:25 halstead: ok, sorted out now, sorry about that May 23 16:41:59 I have it all filled out. Started now. May 23 16:56:44 halstead: thanks! May 23 16:57:19 RP, I'm curious if https://autobuilder.yoctoproject.org/main/builders/nightly-oecore/builds/786 means we need to fix something and start over? May 23 16:57:47 RP I could disable buildtools for the jehtro build. May 23 16:58:53 halstead: that looks like the wrong version of bitbake was specified? May 23 16:59:47 RP, I left it at master since there was no jethro branch at http://git.openembedded.org/bitbake/refs/heads May 23 17:00:14 halstead: Its 1.28 for bitbake May 23 17:00:34 RP, Thank you. I haven't done this in too long. May 23 17:00:51 halstead: takes me a while to rememebr the right options too May 23 17:02:04 RP, Do we need to let https://autobuilder.yoctoproject.org/main/builders/nightly/builds/870 finish? May 23 17:02:39 halstead: its probably worth just killing everything and restarting? May 23 17:02:46 Will do. May 23 17:02:56 halstead: thanks. I'm heading afk for a bit May 23 17:18:46 * kergoth wonders if the recipetool kernel plugin from meta-mel would be generally useful enough to submit to oe-core, or if they're too specific May 23 17:36:42 kergoth: was doing some research yesterday and ran across srctree and gitver. Noticed they are not in current generations of oe-core. Seems like it was useful functionality. Has their use case been subsumed by other methods, like using devtool? May 23 17:44:46 externalsrc is in oe-core, which covers srctree (for the most part) and gitpkgver is generally used to handle the version extraction using the fetcher instead of manual May 23 17:45:12 devtool is the easiest way, yes, but it just does the externalsrc and git repo construction if needed for you May 23 17:46:04 the one major behavioral difference, until relatively recently, was the externalsrc would rebuild every time, as it was flagged nostamp, it didn't track files in the git repo to determine when to rebuild the way the old classes did May 23 17:46:09 kergoth: I'll check them out - thanks. I was helping someone still on daisy, which doesn't have devtool support and looking for alternatives. May 23 17:46:15 but recently that was changed, it checksums the directory tree to monitor for changes May 23 17:46:31 yikes, daisy is getting a tad long in the tooth there :) May 23 17:47:33 i'm not 100% happy with the behavior of externalsrc + gitpkgver, i think if we can assume the external source tree is git we can do a better job of knowing when to rebuild, but it's decent now May 23 17:47:53 ugh, do_populate_lic has no sanity checking to make sure the license files for NO_GENERIC_LICENSE are uniquely named May 23 17:48:03 yes, it is, but they were working with an Altera product and the examples on rocketboards.org were still using daisy. :-( May 23 17:48:08 they get dropped into the license dir and just blindly overwrite previous ones if the basenames are the same May 23 17:48:20 huh May 23 18:29:01 can someone explain why gstreamer1.0-plugins-bad is still on 1.6.3 while all the rest is 1.8.1, causing conflicts between the good and bad plugins? May 23 18:29:19 i.e. the rtp plugin was moved from bad to good, if the 1.6.3 bad plugins are installed, you get errors May 23 18:44:32 * paulg checks git log of the upgraded ones out of curiousity May 23 18:45:30 I seem to recall ubuntu treated "bad" differently due to licensing reasons... May 23 18:45:51 that was some years ago tho... May 23 18:52:25 looks like bad was in the upgrade patch series, just got dropped for some reason.. i'm not seeing anything on the list denying it, so i'm guessing it was an oversight when it was merged? May 23 18:52:30 * kergoth shrugs, repleid to the list and opened a bug, will see May 23 18:55:27 I suspect it was an oversight with 'bad' May 23 18:55:40 I am getting below errors when i tried to link egllibrsris with gstreamer.: hidden symbol `pthread_atfork' May 23 18:58:23 it was merged by RP may 6th ; odd that nobody noticed until now... May 23 19:01:10 i'm guessing folks must not be installing the bad plugins much, the only reason i had them installed for this test was qtmultimedia depends on it (which seems odd, incidentally, but that's another issue..) May 23 19:01:35 not a big deal, though i'd agree it's a little surprising May 23 19:02:46 i am using meta-qt5 (korgoth). i've successfully build the qtdeclarative module from meta-qt5. now i also want to build and package the examples which are part of qtdeclarative module. May 23 19:02:56 how do i do that? May 23 19:03:13 from what i've seen i can only enable the examples for the whole of qt5? May 23 19:03:22 is that correct? May 23 19:15:59 fmeerkoetter: no, that's not correct. qtdeclarative is its own recipe. just PACKAGECONFIG_append_pn-qtdeclarative = " examples" in local.conf, and add qtdeclarative-examples to your image (see the yocto documentation or local.conf.sample/local.conf for how to do that) May 23 19:16:23 kergoth: thanks for the lead! May 23 19:40:23 kergoth: bad was delayed because it broke gst-player, but i never saw any breakage in the plugins May 23 19:44:10 huh. was there feedback to the patch series author? I didn't see anything ont he list, but admittedly it was just a quick search May 23 19:44:18 yeah May 23 19:44:29 (somewhere) May 23 19:50:45 billr, kergoth: Didn't we add enough to the fetcher to allow it to do something like gitpkgver if you configure it right? or did I just remember planning to do that? :/ May 23 19:52:24 rburton, I got a chuckle out of the fact that OSX had the quoting coreutils dain bramage too. May 23 19:52:47 paulg: never got around to finding out how to turn it off :( May 23 19:54:41 seebs and joeythesaint brought it to my attention coincidentally within hours of each other. May 23 19:54:46 RP: it does look like that's what gitpkgv_revision() is for, it was a direct copy/paste from gitpkgv.bbclass in meta-oe, but without the handling for tag-based versions, but i don't see anyone using it, and at the moment it just does a straight commit count, no flexibility there May 23 19:55:36 I hadn't seen it in OS X yet, but then, I'm a version behind there. May 23 19:55:37 I was going to bbappend it into the bitbucket in meta-overc, but then figured it annoyed enough people that it might as well be in OE. May 23 19:58:52 kergoth: would be good to try an reconcile it somehow... May 23 19:59:37 agreed May 23 20:15:03 curious. I get this compile fail after pulling latest updates. May 23 20:15:07 cmake-native/3.5.2-r0/cmake-3.5.2/Source/kwsys/ProcessWin32.c:36:39: fatal error: windows.h: No such file or directory May 23 20:15:07 compilation terminated. May 23 20:15:27 clearly configure went off the rails and thinks this is a windoze box. :-/ May 23 20:15:37 rburton: are you the best person for openssl related patches? May 23 20:17:41 otavio: i certainly hope not May 23 20:17:46 LOL May 23 20:17:48 Who? May 23 20:17:51 paulg: huh, interesting May 23 20:17:59 otavio: what's the problem? May 23 20:18:04 I have three patches for it, for better integration May 23 20:18:13 and moving c_rehash for shell May 23 20:19:43 rburton, looks like it wwas the recent uprev ; configure log has a bunch of these... May 23 20:19:49 System is unknown to cmake, create: May 23 20:20:06 Linux to use this system, please send your config file to cmake@www.cmake.org so it can be added to cmake May 23 20:20:19 whaaat May 23 20:20:26 i'm building cmake stuff right now with current master May 23 20:20:31 umm.. can I send them an email of what I think about 'cmake'.. May 23 20:20:32 * paulg digs in deeper. May 23 20:20:35 (which is why i'm wishing i had a drink) May 23 20:20:38 or would that be politically incorrect? May 23 20:20:54 ARGH May 23 20:21:00 now cmake thinks its cross-compiling in a native build May 23 20:21:01 rburton, this host is meta-overc (i.e. build appliance + a kernel and grub so I can boot it) May 23 20:21:03 DRINK May 23 20:21:31 paulg: cursed cmake must have broken^Wtweaked their linux detection? May 23 20:21:45 rburton, libtool, cmake, perl... all of them could drive you to drinking as a profession May 23 20:21:58 prolly ; won't know till I dig in a bit more.... expect a patch. :-) May 23 20:22:34 fray, should I put that on a resume as a risk that I've already covered? ;-) May 23 20:23:08 risk averted May 23 20:25:38 -rwxr-xr-x 1 ross ross 659M May 23 21:23 libgbe.so May 23 20:25:48 i do love it when a library "links" to llvm May 23 20:26:00 THANKS C++ YOU'RE AWESOME May 23 20:26:45 now to figure out why this fails for me .... May 23 20:26:48 set(CMAKE_SYSTEM_INFO_FILE Platform/${CMAKE_SYSTEM_NAME}) May 23 20:26:48 include(${CMAKE_SYSTEM_INFO_FILE} OPTIONAL RESULT_VARIABLE _INCLUDED_SYSTEM_INFO_FILE) May 23 20:26:48 if(NOT _INCLUDED_SYSTEM_INFO_FILE) May 23 20:26:48 message("System is unknown to cmake, create:\n${CMAKE_SYSTEM_INFO_FILE}" May 23 20:26:48 " to use this system, please send your config file to " May 23 20:34:54 rburton, looks like a perfect candidate for mlockall() May 23 20:35:51 ...on a machine with 512MB ram. :) May 23 20:37:13 paulg: it strips down to a sprightly 300MB May 23 20:37:40 oh well, then what are you complaining about? ;-) May 23 20:38:42 to be fair this is a relatively small package, when i was rebuilding clang every other build that took an hour May 23 20:38:51 15 minutes of which for do_package* May 23 20:42:32 ok, now I know what is wrong with cmake... May 23 20:42:50 it is fallout from the same missing locale files I was discussing with kergoth on Friday. May 23 20:43:22 their platform test is sucking up stderr as well as stdout and getting confused by... May 23 20:43:42 /bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) May 23 20:44:23 it really shouldn't look at stderr, so I guess I'm back to trying to find out why the locale files are built but not installed in rootfs. May 23 20:46:23 RP, kergoth: I'm willing to open an enhancement request for gitpkver, but I'm unsure of what the summary would be.... May 23 20:47:34 * paulg wonders why poky build system (tries to) set LC_ALL to en_US vs "C" anyway.... May 23 20:47:46 paulg: because C doesn't support utf-8 May 23 20:47:59 and py3 *needs* a utf8 locale May 23 20:48:01 python3 requires utf-8 to work properly.. May 23 20:48:12 C.UTF8 isn't universally supported, but en_US.utf-8 is May 23 20:48:25 fray: unless you're on debian and pruned the locales, comedy lol May 23 20:48:34 was writing a sanity test for that today May 23 20:48:37 ok, so I don't _think_ I've anything here locally that would differ from the build-appliance; so it should suffer the same issue. May 23 20:48:39 * rburton doesn't have en_US May 23 20:48:58 * paulg should build the build appliance to be sure. May 23 20:49:09 hmm, I bnetter pull and try newer cmake with gnuradio May 23 20:49:10 I quite like C.UTF8 myself.. really surprises me that is a realitivly "new" locale May 23 20:49:59 # cat /bin/uname May 23 20:49:59 #!/bin/sh May 23 20:50:01 was talking w/ RP about it, may be possible for bitbake to provide it's -own- C.UTF8... but it'd be interesting to see if it really can be universal May 23 20:50:14 /bin/uname.coreutils $@ 2> /dev/null May 23 20:50:23 that should prove if my theory is correct May 23 20:56:18 paulg: the utf8 piece has just landed into OE-Core partly to see exactly how much of a pain this will be... May 23 20:56:46 * RP has tried to avoid it but basically its the least bad solution May 23 21:07:53 RP, ah that could explain why I started seeing this recently ; just not sure how recent recently is... May 23 21:08:59 the uname hack was a fail since the subshell still complained and polluted their borken test, so I've manually installed the en_us goo and all their depends. May 23 21:09:35 waiting to see if that fixes it ; 99% sure it will. May 23 21:10:13 I've a build appliance image building on anotehr box to confirm it has missing locale issue. May 23 21:11:49 yep, with the locale rpms installed, cmake is now happy. May 23 21:11:52 Hi May 23 21:12:11 now I'm still at a loss why these settings in my local.conf don't seem to do anything.... May 23 21:12:14 GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8" May 23 21:12:14 IMAGE_LINGUAS = "en-us en-gb" May 23 21:13:09 * paulg tried to mimic the usage from RTFM. May 23 21:13:48 paulg: Not sure why that wouldn't fix build-appliance but I don't remember the exact syntax for those offhand May 23 21:13:56 we should fix build-appliance if its broken May 23 21:14:40 yeah, I'm building the pristine build-appliance now to confirm it. May 23 21:15:24 meta-overc layer isn't strictly build-appliance, but close. May 23 21:16:41 * paulg might wander off and find food while that build runs... May 23 21:38:53 Hello - I have two different core-image builds for my project, and I want to modify base-files for one of them. How should I name the FILESEXTRAPATHS variable in my base-files_3.0.14.bbappend to handle it? May 23 21:43:37 Circuitsoft: that doesn't really make sense. filespath can't distinguish between what target you'er building or what your build directory is. you can either add a variable to control the difference, and set it in one local.conf but not the other, or use a separate layer, which is only included in one of the two builds May 23 21:45:05 What differentiates core-image-minimal from core-image-minimal-initramfs? Is it just the files specific to that recipe? May 23 21:45:44 Should I just add an fstab file to the core-image-my-server build? May 23 22:21:40 I'm in the process of setting up a brand new team using Yocto as the means of producing reference images for our board. Internal teams will produce the BSP layers and we will work on the application layers. Is there a best practice quickstart on how to organize the location/layout/mapping of git repositories such that one repo-tool manifest can bring in both the core layers, our application layers, and the correct configuration fi May 23 22:26:53 highly unlikely, the repo tool is only used by some projects, not all. there's no single mechanism used for managing multiple git repositories that's used by everyone, as none of them fit all use cases May 23 22:27:11 how you organize your manifest repo is really up to you, the manifest will need every repository explicitly listed regardless May 23 22:58:47 Thanks kergoth. Still there must be some best-practice/teories on how to bring in new layers on a clean way? More specifically, what are some standard build server sequence of commands to pull in the standard yocto layers plus the additional image and/or machine layers? Making a standard core-image-minimal for qemu can be done with just a clean source oe-init-... plus a bitbake. Do you suggest we make our own MY-init-build-env s May 23 22:59:32 use TEMPLATECONF to provide your own default bblayers.conf, or add the others with bitbake-layers after the fact: bitbake-layers add-layer /path/to/a/layer May 23 22:59:40 Or are tehre some pre-config files that can guide some kind of auto discovery of layers such taht the local.conf and bblayers.conf are created with changed settings? May 23 22:59:41 or, yes, create your own wrapper setup scripts May 23 22:59:49 ahh May 23 22:59:54 no, the stock setup scripts provide no layer discovery May 23 23:00:09 that said, bitbake-layers provides commands to pull down layers from the layer index, with dependencies, as another option May 23 23:00:18 TEMPLATECONF sounds like it. Thank you will read more. May 23 23:00:35 it's not super flexible, since it just lets yo uchange the template bblayers.conf, but it often does the job May 23 23:01:17 Still it will produce a bblayers with absolute paths from hinting at additonal local path layers? May 23 23:01:34 you can easily reference paths relative to the bblayers.conf, and then ensure they're cloned to there May 23 23:01:37 but it won't find them for you, no May 23 23:01:49 ok will read more great info thanks May 23 23:01:58 there are folks that have written enhanced setup scripts which wrap the oe-core ones that you could find of interest, depending on your needs May 23 23:03:10 https://gist.github.com/kergoth/11f89fd365d78429e528 covers the features of the ones mentor graphics uses, for example (which are in the public meta-mentor layer) May 23 23:03:15 It seems like a something other people would run into. How to manage both internal feature layers and internal BSP layers with standarrd octo layers in the middle. May 23 23:03:37 Nice checking that out too. May 23 23:03:44 bsp systems and xilinx do their own things along similar lines May 23 23:04:39 you could certainly just script 90% of it in your jenkins job, though that could be hard to deal with in your configuration management. depends on your needs. oe-core provides a minimum that tries to be agnostic of the use cases, but it does mean it's fairly limited May 23 23:06:04 I'd love to use as much of the envvars in the standard script as possible. But yes may have to script/patch stuff in the end, hope not to. May 23 23:26:13 RP, build appliance does in fact list the GB and US locale stuff in the image manifest, so it is on me to determine what changed there since I forked my layer from it. May 23 23:26:29 ...and then make the corresponding changes in meta-overc May 23 23:29:20 I think rburton said he was writing a sanity test for the utf8 presence earlier ; probably a good idea vs ratholing people down into cmake etc. :) **** ENDING LOGGING AT Tue May 24 02:59:58 2016