**** BEGIN LOGGING AT Thu Jul 21 02:59:58 2016 Jul 21 06:14:03 Hi, i have a problem with task in python, how from python function knows that previous task running from cache or not ? Jul 21 06:23:07 hi guys Jul 21 06:26:39 Hi, i have a problem with task in python, how from python function knows that previous task running from cache or not ? Jul 21 06:29:09 anybody don't know it ? Jul 21 06:32:33 if do_compile was running the binares are in $D dir but if not binaries are in $SYSROOT-DESTDIR dir, so i have to overwrite path to files, how know that the task was running ? Jul 21 06:36:00 if do_compile was running the binares are in $D dir but if not binaries are in $SYSROOT-DESTDIR dir, so i have to overwrite path to files, how know that the task was running ? Jul 21 06:37:02 kukowski: you can make your task dependant of do_compile Jul 21 06:38:24 i have to do it in my python function Jul 21 06:39:58 addtask your_py_func after do_compile Jul 21 06:40:08 python your_py_func() {} Jul 21 06:40:13 should do the trick Jul 21 06:44:11 i can't overwrite file with do_compile function, i have to know that do_compile was running from my another file with run_ptest task Jul 21 07:55:42 hey all Jul 21 08:12:34 how does one regenerate the bitbake documentation from the XML ? Jul 21 08:25:25 boucman_work: see the bitbake/doc directory in poky, and the readme there. should come with a makefile. Jul 21 08:26:43 LetoThe2nd: thx, found it... as usuall I asked my question to fast :( sorry about that Jul 21 08:27:12 np Jul 21 08:32:33 I guess most of you end up using multiple layers from multiple sources. Out of curiosity, what do you use to manage the sources? Jul 21 08:34:48 sveinse: you mean the layers ? Jul 21 08:35:13 I mainly do it manually, we do have a custom tool but i'm not very found of it Jul 21 08:35:34 I would recommand having a look at bitbake-layers and repo... Jul 21 08:35:53 repo seems the most common tool to save a yocto build layout... Jul 21 08:36:04 Yes, I am looking at repo. We use it for other collection of git repos Jul 21 08:36:24 sveinse: mirror all upstream external sources on our own machines, couple of shell scripts to regenerate project structures. Jul 21 08:36:41 But you'd need some tool to configure build, such as setting the right dirs in bblayers.conf Jul 21 08:37:02 sveinse: repo can fill in for the latter, but we consider it bloat and missing some features, at least at the time we looked at it. Jul 21 08:37:33 LetoThe2nd: It seems a lot do make such custom scripts. I've seen three variants in three companies now Jul 21 08:37:45 sveinse: yeah, our scripts do all that. complete rebuild of local.conf and bblayers.conf, including checkouts of all needed sources with specific states :-) Jul 21 08:38:03 (and we'll probably make our own as well) Jul 21 08:38:06 sveinse: probably there's 30, 300, or even 3000 of them, Jul 21 08:38:34 yeah so does our script... that's the easy part. the hard part is dealing with the various use-cases of each dev, regenerating the XML description of the layout and uploading it... Jul 21 08:38:50 sveinse: in case you're interested, ours is public https://github.com/LetoThe2nd/blubber Jul 21 08:39:07 sveinse: a major rewrite is underway, but nothing yet to show. Jul 21 08:40:00 LetoThe2nd: thanks. BTW, nice Dune reference :P Jul 21 08:40:14 sveinse: :-) Jul 21 08:42:20 so far, repo is the best tool I have found, though I'd agree with LetoThe2nd about it being not perfectly fitted for yocto. Jul 21 08:42:46 it does have some really cool features though. If I had to write a new tool, i'd definitely base it on repo or on similar concepts Jul 21 08:43:13 This is perhaps an idea for the Yocto SC (if there is one) to set some tool/precendence? Jul 21 08:43:47 SC = Steering Committee Jul 21 08:44:07 the discussion has been there several times. FWIW, the general opinion is "use what fits your bill most, for many people it seems to be repo" Jul 21 08:44:50 I read it as Summer of Code :P Jul 21 08:45:11 i read it as SupaCrowd Jul 21 08:45:30 yeah, I don't like that conclusion. There are dozen of variant of that tool, basically one has been developed by each BSP provider Jul 21 08:45:55 most are heavily broken shell scripts that break whenever you don't do it exactly the way it's meant to be Jul 21 08:46:32 and there would be really added value to yocto if the project used its "authority" to standardize on one tool... even if the tool is not perfect Jul 21 08:46:42 sometime a bad answer is better than no answer at all Jul 21 08:46:47 i personally think its a better opinion than setting so new preference, which would be absolutely prone to be https://xkcd.com/927 one more time Jul 21 08:46:58 Yes, but, the downside is loss of consistency. I'm working in a company that makes end user products, and we use Yocto as a technical base for those products. But often we use subcontractors to supply BSP support. We see a lot of different practices when it comes to coding, and that we then later have to unify those efforts. Jul 21 08:47:50 boucman_work: mind, the conclusion is not "invent something new", but "here, lot at this couple of projects, they use repo." Jul 21 08:47:55 sveinse: that why I think the "authority" part is important. The idea is not to provide a better tool but an authoritative tool Jul 21 08:48:47 yes, defacto working practices work equally well imho Jul 21 08:48:48 tools should convince by quality, not by authority. i strongly disagree here. Jul 21 08:48:50 repo could be the answer... it does have a couple of limitations (having the manifest forced to be in a git repo is one of them, forced autoupdate from google servers is another one) but it is the best tool I know of currently Jul 21 08:49:41 LetoThe2nd: you base your assumption on the idea that BSP providers know how to use yocto/can assert what a good tool is Jul 21 08:50:03 I agree on principle, but I deal with that mess everyday, so I have to disagree in practice Jul 21 08:50:09 No, I'm not too fond of authority either. Because authority means that you can foresee all the use cases for it, and that is hardly the case. Jul 21 08:50:44 boucman_work: whereas you base your assumption on that some steering committee, somewhere else can judge what should fit the workflow of a majority of people. Jul 21 08:50:50 Doing Yocto ports is a proof of that, as I daily encounter something that evidently is not thought of Jul 21 08:51:04 boucman_work: both have up- and downsides. Jul 21 08:51:08 both are assumptions. Jul 21 08:51:10 agreed Jul 21 08:51:42 :-) Jul 21 08:51:56 that's why they are opinions and not decision :P Jul 21 08:53:42 one feature that I really miss on repo is the ability to specify manifest in other thing than git repo... a local directory with the same layout, a tar.gz, or even being able to build a version of repo.py which would self-contain the manifest... that would be awesome Jul 21 08:56:36 (hmm. I had expected that krogoth has support for ubuntu 16.04 :o) Jul 21 08:57:06 sveinse: what's the problem? Jul 21 08:57:35 rburton: No problem, just a note about the warning Jul 21 08:57:48 ah, should work then Jul 21 08:58:00 unlike fedora 24 which needs patches (point release coming) Jul 21 08:58:11 SANITY_TESTED_DISTROS="" is your friend :) Jul 21 08:58:22 (or write your own distro config, poky is an example) Jul 21 09:01:13 Are versions of the various layers tightly bound to each others? Jul 21 09:01:16 I mean Jul 21 09:01:34 if you're using krogoth oe-core then you want to track krogoth of each other branch Jul 21 09:01:44 Hi guys, I have a bitbake dynamic configuration loading question for y'all, anybody not idling in here? :) Jul 21 09:01:54 jubr: ask, don't ask to ask Jul 21 09:02:49 true, it has been years since my last IRC experience, I'm a little rusty :) Jul 21 09:02:59 true, it has been years since my last IRC experience, I'm a little rusty :) Jul 21 09:04:17 I just downloaded krogoth to be able to test qemu/intel build, and I see that the originial meta-qt5 is at jethro. The problem being that I see that we have a lot of local patches to it. To poky, meta-qt5 and meta-openembedded Jul 21 09:05:22 My goal objective is to change our application from one BSP to another Jul 21 09:06:13 why dont you stick with jethro? Jul 21 09:06:56 rburton: Well, it was the missing 'sdl' thing against qemu Jul 21 09:07:33 jethro 2.0.2 is fixed for that Jul 21 09:08:09 rburton: yeah, but I still need to update a patched poky. Which is equally much work as 2.1 Jul 21 09:08:51 well not really, if you're on 2.0.0 then the migration to 2.0.2 is mostly trivial. also, this is why i suggest not patching oe-core/poky directly... Jul 21 09:09:02 I have created an internal release management tool that allows us to maintain opkg feeds with hand-picked software components for our software releases. I've added functionality that writes a release.conf file with the same PN+SRCREV information for each component. The goal is to be able to build an image with these specific software components in them. I'm trying to http fetch + load this .conf file from inside OE. Jul 21 09:09:24 I'm attempting intel/qemu, because I'd hoped that this could serve as a generic playground for porting the app before attepting the real HW BSP Jul 21 09:10:01 absolutely sensible Jul 21 09:10:29 intel and qemu targets have always worked, just grab meta-intel and use the right branch if you want to boot on real x86 Jul 21 09:10:50 But I'm running into problems when dynamically loading the release.conf - since it does not yet exist at OE-start time. I've added caching. But now the conf information only seems to be available in the Recipe Parse phase, it does not seem to reach the worker threads. Jul 21 09:12:28 rburton: cool Jul 21 09:13:49 I've `release_conf_fetch_and_cache[eventmask] = "bb.event.ParseStarted"` and then use `bb.parse.handle(release_conf_cache_path, d, True)` to dynamically load it Jul 21 09:13:56 rburton: We have like 10 patches or so on poky. Most about bugs/features in poky that does not play well on the specific HW Jul 21 09:14:57 But I definitely see the issue here. I'm now stuck when considering other vendors/BSPs Jul 21 09:15:21 sveinse: vendors which don't track oe-core releases are a right pain Jul 21 09:15:44 *but* if you have a final target BSP then use the release they support Jul 21 09:15:52 qemu and real intel will build on every release Jul 21 09:16:13 hopefully you cloned poky and branched? Jul 21 09:18:25 No, it does not seem that way. And yes, I will direct the ranting in their direction, not here. So for the record, I'm not asking here to fix/undo what has been done. I just need humble advice on how to move forward. Jul 21 09:19:34 clone poky, branch it where your BSP starts from, copy your patches in, commit, rebase to the latest stable release to get the sdl/qemu fixes, party. Jul 21 09:24:05 I have a set of layers that has been modified to fit one particular BSP and system. system might be our requirements to the available software. When moving to another HW and BSP I can do one of two things: I can either start with a clean slate and work off official releases. Then I fear that I have to redo and relearn all the quirk and patches that has already been implemented into the... Jul 21 09:24:07 ...former BSP. The other option is to build on the previous BSP, but that gives on a strong tie-in to what has already been done, and it already being surpassed by newer versions. Jul 21 09:25:17 I'd hoped on the latter, as it gives us freedom to move across BSP, but I fear the unknown amount of work that it might imply Jul 21 09:30:55 rburton/sveinse: interesting BSP/release discussion, we're currently doing something similar with i.MX6 + Freescale's official Yocto release Jul 21 09:32:08 I've managed to keep most changes in our own BSP meta layers with .bbappend and 2 or 3 .bbclass overrides. Jul 21 09:38:02 jubr: this is in fact a imx6 bases BSP too, custom HW thou Jul 21 09:38:46 based on what board ? Jul 21 09:39:06 with Qt5 for graphics, and that certainly increases the complexity by a few notches Jul 21 09:39:21 Ours too, i.MX6 SoloX Jul 21 09:40:10 sveinse: did you bae on the latest Freescale release? Do you have grapics acceleration on your board? Jul 21 09:40:20 boucman_work: something called pandaboard I wonder. I have always been working with our custom HW, so I don't really know Jul 21 09:40:53 ok, i've never used taht one, I don't know how good their BSP would be Jul 21 09:41:07 Ours is based on imx6sxsabresd ref design. Jul 21 09:41:12 * boucman_work uses a custom board based on the apalis by toradex Jul 21 09:41:25 but we don't use their BSP, we use what they provide in meta-fsl-extra Jul 21 09:41:57 ah, yes, saw a ref to it in there somewhere. Includes a custom kernel I believe Jul 21 09:42:30 yes, but it works when you do your own build based on poky and just changing MACHINE so I'm quite happy Jul 21 09:42:44 jubr, hmm, sabre, that sounds awfully familiar. Jul 21 09:43:05 rburton: know anything about Bitbake internal .conf parsing with bb.parse.handle()? Jul 21 09:43:13 * boucman_work has some very bad memory of a BSP that would download/rebuild a standard poky for another board, untar the rootfs, override the kernel and a couple of other stuff, then build a SD image based on that Jul 21 09:43:15 jubr, I honestly don't know what version, as we put the porting and implementation to a subcontractor. Jul 21 09:43:17 if was horrible Jul 21 09:43:29 I'm just getting my hands wet with Yocto.... Jul 21 09:43:37 that's the sort of stuff that makes me think that standardizing on a deployment tool would be a good idea :P Jul 21 09:43:41 jubr, but we do have gfx acceleration for Qt Jul 21 09:44:05 http://www.nxp.com/products/software-and-tools/hardware-development-tools/sabre-development-system/sabre-board-for-smart-devices-based-on-the-i.mx-6solox-applications-processors:RD-IMX6SX-SABRE Jul 21 09:44:23 sveinse: sabrelite and sabreauto are the reference dev board for i.mx designed by freescale Jul 21 09:44:51 or am I messing up with the nitrogen, I tend to mix those two Jul 21 09:44:55 yep, now aqcuired by NXP Jul 21 09:45:54 jubr, bases on sabresd Jul 21 09:46:55 sveinse, ah that's good, which kernel ver? 3.14.38, 3.14.52? I saw they have a new 4.1.15 release out. We're still working with .52 here. Jul 21 09:48:19 boucman_work: Freescale's BSP is actually quite good I think. Full support for all the featues on all of their i.MX6* boards from one bsp release. Nicely done. Jul 21 09:48:20 jubr: .38 Jul 21 09:48:44 have any of you been working with Veriscite boards? Jul 21 09:48:58 That is the BSP I'm porting my app to... Jul 21 09:49:04 sveinse: we had someone from NXP port our .38 changes to .52 release. It's doable. I wonder how much work migrating to 4.1 will take... *sigh* Jul 21 09:49:20 sveinse: nope Jul 21 09:49:38 I did, but I don't remember what project it was... Jul 21 09:50:00 I think the BSP was quite messy, but I don't remember the specifics... Jul 21 09:50:09 AM33 not their imx boards Jul 21 09:51:22 Ah, ok, we're looking at the imx6 based boards. We're peeking at the 6UL architecture Jul 21 09:52:40 might be cleaner, then... Jul 21 09:52:41 We settled for the 6SX, we needed the ADC's + gfx. Now have 512M RAM + 4G eMMC. /me happy :) Jul 21 09:53:26 Yeah, we're not sure the 6UL has enough juice for what we need it to do. So it's a concept test Jul 21 09:58:00 haha, with reference to our previous discussion about repo/layer management. Variscite apparently have their own. Jul 21 09:58:26 I think I'll name my tool yalcmt. yet another layer configuration management tool Jul 21 09:58:40 sveinse: nice Jul 21 09:59:29 I'm starting to appreciate google repo. Now if we would only start to use sha's in our manifest instead of moving-target-master refs :) Jul 21 10:04:36 * CTtpollard uses submodules Jul 21 10:04:47 mainly because nty google Jul 21 10:09:48 for scm that's nice, but I suppose you have script for build conf as well? Jul 21 10:10:41 yes Jul 21 10:43:09 @all: anybody here know anything about Bitbake internal .conf parsing with bb.parse.handle()? Jul 21 10:43:57 Does any of you use external sources? Our software is a humongous hg repository, and (on 2.0.1 at least) hg support seems iffy. But when I attempted to use EXTERNALSRC on 2.1 yocto stops at: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception IOError: [Errno 2] No such file or directory: '/home/nosse1/yocto/sp/repos/sp/.git/inde Jul 21 10:43:59 x' Jul 21 10:44:35 So it apparently wants it to be a git repo Jul 21 11:02:37 bitbake patch submitted, hopefully will get in Jul 21 11:02:44 * boucman_work <= noob enthusiasm Jul 21 11:03:25 * jubr is appreciative :) Jul 21 11:13:27 Sorry to repeat, but how do I get past this: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception IOError: [Errno 2] No such file or directory: '/home/nosse1/yocto/sp/repos/sp/.git/index' Jul 21 11:23:06 * sveinse giving up Jul 21 11:24:15 sveinse: does not ring a bell, sorry Jul 21 11:24:19 PS did you see http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119334.html Jul 21 11:26:29 Ah, I think I know what it is. We use hg, and some submodules that happens to be git repos. hg has some configs in .git, which later makes BB think its a .git repo. Jul 21 11:26:33 Isn't it lovely? Jul 21 11:26:33 sveinse: that is a complicated question, chances are very few people can answer :( Jul 21 11:26:56 * jubr my pleasure :) Jul 21 11:27:05 sveinse: yeah, i think the problem is that your repo has a .git/ in it, but srctree_hash_files() can't find the files it expects in it Jul 21 11:27:06 sveinse: tbh, a .git/ directory is the standard way of detecting a git repo :P Jul 21 11:27:20 Same as my intro + question above. No-one knows. Jul 21 11:27:26 * jubr *sniffs Jul 21 11:27:31 sveinse: you'll find the source for srctree_hash_files() at the bottom of meta/classes/externalsrc.bbclass btw Jul 21 11:27:38 yup, but I think I have the answer Jul 21 11:27:57 Ulfalizer: thanks, I'll look at it Jul 21 11:29:55 I think this is rather ironic. Didn't we start out the discussions today that we should try to avoid patching poky? Well, it seems, that there are lots of cases where its unavoidable :P Jul 21 11:30:05 No pun intended, thou Jul 21 11:34:54 I know. I even have a custom base.bbclass with patch to make the files do_fetch writes in ${DL_DIR} group writeable Jul 21 11:35:49 I've set up a shared OE build env for our developers with shared DLs+ sstate. Hugely speeds up dev time + space reduction. Jul 21 11:36:20 cool Jul 21 11:37:56 jubr, btw, if you have a CI server, or a build server, how far back do you take each build to ensure consistency? E.g. Do you wipe tmp/ Jul 21 11:40:50 We need to set up some similar scheme for sstate cache from a central build server. IT is already on my back for completely blowing up the requirements for the developer machines when working with Yocto. Jul 21 11:41:03 jenkins, wip, currently not done yet. At least all releases are built with it though. I should make a second job that does a clean rebuild every now + then. Jul 21 11:41:22 * jubr is wondering if there is such a thing as SSTATE_EXLUDE = "recipe1 recipe2"? Jul 21 11:41:59 sstate mirror stuff exists though Jul 21 11:51:19 Trying to build a recipe for a kernel module, I keep falling over because version.h isn't in the kernel src directory and it ends up using the host system's (which in this case, doesn't match at all) - I can see the generated version.h in the work directory, but it's not in the work-shared directory... Anyone know what's up with that? Jul 21 11:54:15 zeddii zeddii_home ^ Jul 21 11:54:58 well, when I say I see it in the work directory, I see it in the sysroot directory for an image that ends up with it and I see it in the work directory of linux-libc-headers Jul 21 11:56:32 rburton: architecture question : I want to add a way to expand bb variables in target files (typically they come from "SRC_URI=file://" and end somewhere on the target's "/etc" Jul 21 11:56:51 so somewhere on the do_fetch => do_unpack => do_patch chain Jul 21 11:57:21 should I try to do that in bitbake, somewher in fetcher2 or should I keep it yocto specific in the way do_patch is in patch.bbclass ? Jul 21 11:57:43 latter Jul 21 11:58:06 i'd write a class that adds a task between patch and compile Jul 21 11:58:15 if you had lots of recipes that did the same thing Jul 21 11:59:00 rburton: does a way exists to manipulate recipe's bb.data from inside a handler? Jul 21 11:59:12 ok, thx Jul 21 11:59:42 I just found out event.py's execute_handler() does `del event.data` :'( Jul 21 12:02:34 in a way that it actually propagates to the tasks Jul 21 12:08:26 Hi. It seems like when I do incremental generation of my image's SDK with -c populate_sdk, each time the SDK gets a little bigger. I'm building the SDK with the kernel-devsrc package, and in the target's sysroot I have a pretty big /usr/src/kernel/.kernel-meta/ directory. I'm wondering if that could/should be discarded ? Jul 21 12:09:57 (This is with pretty recent poky-master) Jul 21 12:22:33 jkroon_: that doesn't seem right Jul 21 13:02:13 what's the cleanest way to set up a local source mirror for multiple builds to share? I know for a single pipeline the easiest method is to populate it with the output of an initial download_dir, but doing this for 'x' targets will create a lot of crossover Jul 21 13:03:48 run all x targets with $DL_DIR pointing to the same folder? Jul 21 13:05:14 zeddii, ping Jul 21 13:16:54 CTtpollard: bitbake world -c fetchall Jul 21 13:17:04 neverpanic: ok, so share dl_dir & source_mirror in each local.conf? Jul 21 13:17:25 but yeah, if they're all local, then they can share DL_DIR Jul 21 13:17:28 (and SSTATE_DIR) Jul 21 13:17:58 ok, well I'm currently inheriting the local mirror, I'll also share dl_dir as the same location Jul 21 13:21:48 rburton, I may have spoke to soon. I did a -c clean -c cleansstate virtual/kernel and kernel-devsrc, rebuilt the SDK and it still comes out as big as before. hmm. Jul 21 13:21:59 rburton: are you admin on the bitbake ML ? or should I wait for RP to be around ? Jul 21 13:22:13 disk is certainly a premium when working with yocto. How can I clean a build when an image is done, yet allow me to work on it? If I have understood things correctly, sstate will cache most packages, right? Jul 21 13:23:12 boucman_work: no, yes. Jul 21 13:23:17 boucman_work: I did look at your patch you pasted here yesterday and looked good Jul 21 13:23:24 rburton: CTtpollard: I'd advise against bitbake -c fetchall, because that just fetches but doesn't check whether what you have fetched actually builds, so you might populate your download cache with broken files. Jul 21 13:23:40 sveinse: if you find yourself running out of disk, you can inherit rm_work so it will delete the work directory when its finished building a recipe. Jul 21 13:23:52 boucman_work: I'd just want to check with kergoth about whether that is the right naming for the syntax Jul 21 13:23:57 sveinse: (or get a bigger disk) Jul 21 13:24:13 neverpanic: yeh that's a good point to consider actually Jul 21 13:24:15 sveinse: you can always safely rm -rf tmp/ without loosing too much time, since you still have sstate Jul 21 13:24:43 CTtpollard: We've seen it a couple of times where downloads failed and files in our download cache wouldn't even extract properly anymore Jul 21 13:24:59 In theory, that should never™ happen. Jul 21 13:26:09 rburton: (I wish I could get bigger disk. But company policy and all that. Have to use branded disks under the manufacturers reccomendation is a must, and I'm maxed out already. -- and I'm not ever going to go over to spin drives again.) Jul 21 13:26:51 sveinse: i still endorse spinning rust for build disks as they're so much larger and given enough ram the performance improvement is actually negliab;e Jul 21 13:28:19 I wonder if I could get away with an external USB3 drive... Jul 21 13:28:47 hmm, the drives they put into these are probably too slow thou. 5400s as such Jul 21 13:30:01 RP: I just subscribed to the bitbake ml and posted my patch Jul 21 13:30:30 problem is, my patch is curently in the moderator queue because my company was bought so our email adresses changed, and I goofed up my git-send-email config Jul 21 13:30:40 just wanted to point it out so there is no mess-up Jul 21 13:31:03 (if you our kergoth don't like the syntax, no problem) Jul 21 13:31:13 Heh, my attempt to build our Qt code on qmeu worked. What didn't work is execution. It crashes. So, someone is going to say "I told you so", but all I need to generate USB images for intel and to native boot is to pull in meta-intel ? Jul 21 13:31:58 neverpanic: We have a patched base.bbclass to make the files do_fetch writes in ${DL_DIR} group writeable, so it can be used by multiple developers Jul 21 13:33:24 sveinse: throw enough ram at the problem and you'd be surprised how little the disk is used Jul 21 13:34:32 jubr: I use local mirror rather than shared download... not sure how well shared downloads work... Jul 21 13:35:40 sveinse: add meta-intel, use intel-corei7-64 or -core2-32 machine as appropriate, copy the resulting .hddimg file to a usb stick Jul 21 13:35:55 rburton: Thanks Jul 21 13:36:48 boucman_work: pretty well, actually, with the umask patch. Note that changing base.bbclass will trigger a full rebuild, including cross-compiler + libc. Jul 21 13:39:15 rburton: So all of these intel boards/machines have equal semblence to standard PC HW, right? Jul 21 13:39:27 depends what you mean Jul 21 13:39:41 the intel-core* BSPs target "standard" machines Jul 21 13:39:45 minnow counts as standad Jul 21 13:39:56 edison and galileo are a bit more special Jul 21 13:40:21 rburton: it't nice to be intel in this respect :P Our systems /are/ standard by definition :P Jul 21 13:42:50 I'll probably used some old washed out laptop for testing, so I corei7-64 is probably too new. core2-32 it is Jul 21 14:01:37 What do you guys do for configuring and package splitting? Please let me elaborate: Jul 21 14:05:45 We have a large codebase which must be configured. This configuration decides what gets installed. When supporting multiple MACHINEs (same tune), I am torn between doing this selection in configure-time, so that I don't have to do FILES-splitting. But, that requires one build for each MACHINE. Or configuring it generic (to tune), but then I need to maintain package splitting during installation. Jul 21 14:08:06 sveinse: can't you split it into multiple recipes? Like qt-*? Jul 21 14:08:45 jubr, I can. But then implies multiple compilations of the same code, doesn't it? Jul 21 14:08:58 (without having looked at what qt-* does) Jul 21 14:10:33 Depending if everything needs to be compiled. We kept our codebase component-based, in separate executables actually, communicating locally. This actually makes for a robust, somewhat crash-resistant architecture. Building + Packaging can then be done separately as well. Jul 21 14:11:07 sveinse: i lean towards build-everything-one for the tune, split up in packaging, then each image or machine can pull in the packages that it needs Jul 21 14:11:36 * jubr agrees Jul 21 14:12:53 ...which actually makes the most sense, I think, so I concur as well. Jul 21 14:13:50 Do you use the opkg feeds to update in the field, or are all sw updates monolithic? Jul 21 14:15:24 sw updates are monolithic. We tried in field package updates in our old OMAP based system, which turned out to be too slow. Nobody would wait 40 mins for a SW update. Monolithic took 5 mins Jul 21 14:15:55 ubuntu deb bases thou. We're migrating to Yocto now Jul 21 14:20:41 We've been doing incremental going on 8 years now. Just adding monolithic actually, to add some flexibility wrt system/rootfs updates. Jul 21 14:21:08 The Qt pkg updates could be a bit slow though, true enough. Jul 21 14:21:48 Yeah. Our storage system (sdcard) is painfully slow, so it didn't work out Jul 21 14:22:37 We have UBIFS on our old i.MX27 devices. Nightmare. Jul 21 14:24:18 If I in my recipe want a feature flag, such as with-graphic, what is the common method of doing this in yocto? Can anyone point out an example, please? Jul 21 14:24:34 I'm thinking if this setting belongs in local.conf or not Jul 21 14:25:08 (and I have to learn this override stuff, since it translates to real changes in DEPENDS and RDEPENDS) Jul 21 14:25:48 sveinse: is that something that will vary by machine and won't be changed otherwise? Jul 21 14:28:29 rburton: By role, actually. Which also implies machine. That is the "controller" role must have a display, so it only works on a specific machine with display. Jul 21 14:29:12 I'm starting to think if I want something like "core-image-controller" Jul 21 14:30:24 But that doesn't work too well with the TUNE thinking, as you'd have to configure Qt with graphics in both cases Jul 21 14:30:48 is qt not split into graphical and non-graphical bits anyway Jul 21 14:31:04 so even if you build all of qt5 but only link to the core, you don't pull in the graphical bits Jul 21 14:31:50 rburton: Yeah, but to build qt5 you need to build it with graphics, don't you? Even if you dont pull in the non gfx libs Jul 21 14:32:10 So you end up having to supply some opengl lib for qt, which you eventually might not need Jul 21 14:32:51 ergo, on a MACHINE that does not need gfx, you don't need to configure it with gfx at all Jul 21 14:32:53 but if you never install it and you'll be sharing from sstate anyway and you'll be building qt with graphics later, what's the problem? Jul 21 14:33:21 sure if you have a machine that never has graphics then say so in the machine config, and qt will never build with graphics Jul 21 14:33:26 well, tune. Jul 21 14:34:40 qt5 is built to tune it seems Jul 21 14:35:02 which I tend to prefer, since its more generic Jul 21 14:36:01 yeah Jul 21 14:36:32 if you have various different configurations which have the same base hardware but different software, just build several different images Jul 21 14:36:57 and hopefully the pieces you use can build modular enough Jul 21 14:38:03 I think you can choose to build parts of Qt (qt-base) without the graphical stuff (qt-declarative) Jul 21 14:38:14 So I have two machines, two HWs, "A" and "B". Same tune. The former with display, the latter without. The main application is built off the same codebase. Now my job is to test out a new MACHINE/BSP for "B", but I don't want to bother getting gfx up and running on it, so I need somehow to allow my recipe to not take use of any gfx Jul 21 14:38:58 are we talking opengl or x11 or something else Jul 21 14:39:24 qt5 with opengl Jul 21 14:39:35 imx6 based Jul 21 14:41:08 I just remembered seeing that qt5 has some feature selector system when configuring. I'll take a look at it Jul 21 14:42:19 packageconfig variable Jul 21 14:44:14 hi everyone Jul 21 14:44:24 sveinse: you have to chose if you want to share qt5 between tunes or not. Jul 21 14:44:43 rburton: Yes I do. Jul 21 14:44:52 sveinse: if you don't then make it machine-specific and remove opengl/x11/etc from the machine with no GL. if you do then you have to do a build with graphics. Jul 21 14:45:10 I can tag on to something like this from meta-qt5: PACKAGECONFIG_GL ?= "${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}" Jul 21 14:45:26 yes but thats tune-wide Jul 21 14:45:54 ah, right Jul 21 14:46:17 you could use a different distro for controller and worker, but then you'll likely be causing more builds Jul 21 14:46:35 got a problem building an image for the raspberry pi 3. i always get this error: "/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/python-dbus_1.2.0.bb, do_configure) failed with exit code '1'" and "configure: error: could not find Python headers". any hints? Jul 21 14:47:24 sveinse: I tend to think that if the machines have any difference, then they are not the same MACHINE (they will still share everything that is not MACHINE specific) Jul 21 14:47:38 sveinse: Maybe something like DISTRO_FEATURES_remove_machineB = "opengl" ? Jul 21 14:48:27 jubr: DISTRO_FEATURES are not supposed to change from machine to machine... that would cause everything to rebuild every time you switch machine Jul 21 14:48:37 Hmm.. good point Jul 21 14:50:20 sveinse: does the qt + gfx build ok for machine B? Jul 21 14:50:36 I'm thinking loud here: "A" and "B" as we have it today is two different MACHINEs, but evidently the same tune, as most code is built to tune. including Qt. So moving to variscite imx for "B", would imply new MACHINE, but quite possibly a new tune as well. So there is no benefits for code reuse there. Jul 21 14:51:17 jubr: It does for old "B" as its the same tune as "A". And qt + gfx apparently belongs to tune. But I don't know for new "B" Jul 21 14:51:22 would it be a different tune ? tune is usually linked to cpu type, and both are imx6 iiuc Jul 21 14:52:05 I don't now yet. It's a completely different yocto setup and BSP, so I have no idea Jul 21 14:53:45 k Jul 21 15:03:14 I just need to comment out the lines with sdl in local.conf on older yocto releases to get compilation going on ubuntu 16.04? Jul 21 15:04:10 Just downloaded variscite's current yocto release... Jul 21 15:04:31 sveinse: on any release, assuming it supports libsdl-native. Jul 21 15:06:48 well it failed. complains "Install SDL devel", yet it is. Similar to what we talked about previously. Just this time around, I don't care about sdl if I can avoid it. (Don't know the implication of it thou) Jul 21 15:06:56 hi guys Jul 21 15:07:21 What is the correct approach to do a bootable image with a rootfs greater than 4GB? Jul 21 15:08:26 i've got a problem building an image. i always got the error that the python headers couldnt be found. Jul 21 15:08:37 sveinse: what version of yocto is variscite based on ? Jul 21 15:09:37 boucman_work: how can I find out? Jul 21 15:11:29 any clues? Jul 21 15:14:18 sveinse: when bitbake run, it usually show what branches were actually cloned, usually they are using the yocto version name Jul 21 15:18:23 boucman_work: It does not. It somewhere around 2.0 or 2.0.1 I think. Strange thing is I find the 2.0 tag in both (variscite tree and vanilla poky), but after this they vary a lot. I find /some/ patches from vanilla poky in the variscite tree. (Hmm, need to familiarize myself better with git it seems) Jul 21 15:26:53 sveinse: can you not try rebasing the vendor branch on top of 2.0.2? Jul 21 15:30:12 oO Jul 21 21:03:58 how can basing WORKDIR on MULTIMACH_TARGET_SYS be safe? MULTIMACH_TARGET_SYS only seems to include the "type" of the machine (PACKAGE_ARCH, TARGET_VENDOR, TARGET_OS). what if some recipe overrides variables based on the specific MACHINE? wouldn't that cause collisions, since MACHINE isn't included in MULTIMACH_TARGET_SYS? Jul 21 21:04:37 Ulfalizer: that makes the recipe machine-specific, which changes MACHINE_ARCH and therefore PACKAGE_ARCH Jul 21 21:05:30 well, it may change them automatically under certain circumstances, but you should really explicitly set PACKAGE_ARCH = "${MACHINE_ARCH}" in the recipe if you know you're making it machine-specific Jul 21 21:07:07 what if you have two different machines with the same MACHINE_ARCH? is that supposed to never happen? Jul 21 21:08:11 bluelightning: what i'm *really* wondering though is whether the descriptions in the last comment of https://bugzilla.yoctoproject.org/show_bug.cgi?id=9988 are accurate :) Jul 21 21:08:12 Bug 9988: enhancement, Medium, 2.2 M3, srifenbark, IN PROGRESS REVIEW , Suggested clarification of the STAGING_DIR_* glossary entries Jul 21 21:11:54 Ulfalizer: looks fine to me Jul 21 21:12:04 great, thanks! Jul 21 21:12:16 IMO the PACKAGE_ARCH / MACHINE_ARCH discussion doesn't really belong at this level, because that happens via PACKAGE_ARCH Jul 21 21:13:20 wasn't going to add anything to the glossary entries re. that. i was just curious. Jul 21 21:14:44 bluelightning: would it still be good if i changed "uniquely identifies the type of the target system" to "uniquely identifies the target system"? that's a bit more concrete. i only wrote "type of" because i wasn't sure if the same MULTIMACH_TARGET_SYS value could cover multiple machines. Jul 21 21:15:37 well, it does often cover multiple machines - in fact the default is for it to be architecture-specific not machine-specific Jul 21 21:16:16 FWIW, I think that change will be too subtle for most readers to make a distinction in any case Jul 21 21:16:38 in that case i'm probably still missing something. if two packages use the same architecture but specialize on the machine, then it seems it'd collide. Jul 21 21:17:34 but maybe you can't "specialize on the machine"... Jul 21 21:17:50 in a way that makes sense here at least Jul 21 21:17:57 ah well, i'm happy as long as the current description makes sense Jul 21 21:20:21 Ulfalizer: using the same PACKAGE_ARCH and then customising per machine will break things in a multi-machine build and shouldn't be done (assuming it does not trigger PACKAGE_ARCH to change to ${MACHINE_ARCH} automatically, which it will under some circumstances) Jul 21 21:22:16 bluelightning: alright... then i think i'm following how it works at least. thanks! Jul 21 21:22:33 hi guys Jul 21 21:22:49 hello Jul 21 21:24:10 i've got a problem with building an image for the rpi 3. every build stops with the error buildDir/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/python-dbus_1.2.0.bb, do_configure) failed with exit code '1' Jul 21 21:24:18 can anyone help me? Jul 21 21:26:06 BlitzBlizz: do you get any other error messages? Jul 21 21:26:18 which host? Jul 21 21:26:22 configure: error: could not find Python headers Jul 21 21:26:35 debian 8 virtual machine Jul 21 21:27:40 I saw the same error while build testing for 2.1.1 fix for Fedora-24 Jul 21 21:27:47 but I did not investigate any further Jul 21 21:28:37 i sucessfully built a image before and after that i added meta-networking and meta-python to the bblayers.conf because i wanted a proftpd and since then this error pops up Jul 21 21:29:13 did you checkout the "krogoth" branch of meta-openembedded? Jul 21 21:29:31 yes Jul 21 21:30:06 can you pastebin the log? Jul 21 21:30:27 this branch https://github.com/openembedded/meta-openembedded.git Jul 21 21:31:31 that's the repo, but you need https://github.com/openembedded/meta-openembedded/tree/krogoth Jul 21 21:32:57 but I need to see the output of the config log to help any further Jul 21 21:33:53 here is the pastebin Jul 21 21:33:54 http://pastebin.com/m6ge5fJe Jul 21 21:35:28 i just wanted to built in a ftp server. Jul 21 21:37:25 BlitzBlizz: try adding 'export BUILD_SYS' and 'export HOST_SYS' to the recipe. dunno if it's the proper solution, but it might fix it. Jul 21 21:37:36 jinx Jul 21 21:37:54 That's the exact same failure I saw and the same solution I thought of trying (but didn't) Jul 21 21:38:19 which recipe? Jul 21 21:38:33 BlitzBlizz: python-dbus_1.2.0.bb Jul 21 21:39:04 is it possible to exclude python-dbus? Jul 21 21:39:39 if you search the pastebin for "Error:", you'll see that some os.getenv()'s are failing, which in turn causes a .replace() to fail Jul 21 21:39:52 they return None, and that makes .replace() unhappy Jul 21 21:39:54 yes i saw this Jul 21 21:39:59 BlitzBlizz: not sure Jul 21 21:40:18 * Ulfalizer found https://lists.yoctoproject.org/pipermail/yocto/2014-May/019863.html as well Jul 21 21:40:35 https://github.com/openembedded/openembedded-core/blob/krogoth/meta/recipes-devtools/python/python-dbus_1.2.0.bb Jul 21 21:40:50 has the exact fix Ulfalizer mentioned. Jul 21 21:41:05 so you can PNBLACKLIST the one from meta-python temporarily Jul 21 21:41:54 (and we should probably consider dropping the one from meta-python) Jul 21 21:42:04 ok. i will give it a try Jul 21 21:43:48 I know the one from core built ok for beaglebone machine Jul 21 21:45:30 do i have to built a completely new image? (fyi: i'm new to the whole embedded/yocto thing) Jul 21 21:46:02 bitbake is smart enough to carry on where it left off Jul 21 21:46:21 i did this and the same error appears Jul 21 21:47:20 i just moved the original .bb file and used the one from the link above Jul 21 21:47:33 where did you move it? Jul 21 21:47:44 to bb.bakcup Jul 21 21:48:01 renamed Jul 21 21:48:09 ok... try running bitbake python-dbus -c cleansstate and then try rebuilding again Jul 21 21:48:16 not great if that's needed though Jul 21 21:48:45 maybe adding exports is an obscure-enough case Jul 21 21:49:31 error persists Jul 21 21:49:56 BlitzBlizz: try adding random junk to the bb file to make sure you didn't mess up :) Jul 21 21:50:10 as a sanity check Jul 21 21:50:16 to see that it's getting used Jul 21 21:50:33 (or delete tmp and rebuild from sstate) Jul 21 21:50:42 but that's a heavier hammer Jul 21 21:51:03 this takes 3 hours to rebuild :-) Jul 21 21:51:05 BlitzBlizz: try running just bitbake python-dbus Jul 21 21:51:11 not with sstate it won't Jul 21 21:52:23 double negative. my grammar has gone south Jul 21 21:52:40 sanity check successfull Jul 21 21:52:46 parse error Jul 21 21:53:07 bitbake -c cleansstate python-dbus && bitbake python-dbus Jul 21 21:53:17 (after you fix the parse error) Jul 21 21:53:26 parse error implies you make a typo Jul 21 21:53:43 * rburton is done for drive-by contributions and passes it back to moto-timo :) Jul 21 21:53:46 g'night :) Jul 21 21:53:49 lol Jul 21 21:54:05 moto-timo: good try with #99999 but i saw through you cunning plan Jul 21 21:54:06 g'night Jul 21 21:54:18 rburton: of course you did Jul 21 21:54:21 wish we had more to redistribute :( Jul 21 21:54:21 it was just for the laugh Jul 21 21:54:32 there should be ~3 in JF somewhere Jul 21 21:54:51 we need to kickstart another run Jul 21 21:54:54 i wonder if davest has some in a drawer somewhere Jul 21 21:55:01 yeah that would mean doing a 3d scan of a existing one Jul 21 21:55:08 the model is way lost Jul 21 21:55:08 this "bitbake -c cleansstate python-dbus && bitbake python-dbus" produced the pastebin again Jul 21 21:56:13 i may have "liberated" a copy of the entire openedhand git server before it got shut down post-acquisition and the model was never archived in the artwork repo :( Jul 21 21:56:22 bummer Jul 21 21:56:54 yeah Jul 21 21:58:32 BlitzBlizz: do you have some other python-dbus* bb files besides the python-dbus_1.2.0.bb one? Jul 21 21:58:58 and does that one have 'export BUILD_SYS' and 'export HOST_SYS' in it? Jul 21 21:59:07 ^^^ very important Jul 21 21:59:08 python-dbus_1.2.0.bb that is Jul 21 21:59:55 only python-dbus_1.2.0.bb and python-dbus_1.2.0.bb.backup Jul 21 22:00:20 BlitzBlizz: and python-dbus_1.2.0.bb and python-dbus_1.2.0.bb.backup Jul 21 22:00:20 Day changed to 22 Jul 2016 Jul 21 22:00:24 wups Jul 21 22:00:32 pastebin the entire recipe and the whole cooker log i guess Jul 21 22:00:49 BlitzBlizz: and have you double-checked that you have those two export's in it? Jul 21 22:00:59 and are you getting the exact same errors as before? Jul 21 22:02:07 yes i checked it. export BUILD_SYS export HOST_SYS are in python-dbus_1.2.0.bb file Jul 21 22:02:20 BlitzBlizz: on separate lines? Jul 21 22:02:24 yes Jul 21 22:02:31 ok... adunno then Jul 21 22:02:36 seems odd Jul 21 22:02:42 odd indeed Jul 21 22:03:21 i made some little changes to the local.conf. i don't know if this can cause the error Jul 21 22:04:41 i added "IMAGE_INSTALL_append = "proftpd" to the local.conf Jul 21 22:04:59 is this the right way? Jul 21 22:06:22 You're not even getting to the point where this matters when running bitbake python-dbus, but there should be a space before proftpd, since _append doesn't add one Jul 21 22:08:18 bblayers.conf: http://pastebin.com/5uFNhuEB local.conf: http://pastebin.com/YN16naiv Jul 21 22:10:45 that bblayers.conf is truncated Jul 21 22:11:17 (there's no closing ") Jul 21 22:11:33 so probably didn't catch it all when you copied Jul 21 22:13:33 this "bitbake -c cleansstate python-dbus && bitbake python-dbus" produces this: http://pastebin.com/SUwmJv0j Jul 21 22:13:57 the closing " is there. didn't catched it Jul 21 22:20:33 BlitzBlizz: is /home/debian1/buildDir/poky-krogoth-15.0.0/meta-openembedded/meta-python/recipes-devtools/python/python-dbus_1.2.0.bb the file with the added exports? double-check. Jul 21 22:21:01 strange that it isn't showing meta-oe, meta-networking and meta-python in the build output... Jul 21 22:21:30 should be seeing: Jul 21 22:21:41 meta-oe Jul 21 22:21:44 meta-python Jul 21 22:21:46 meta-networking = "krogoth:247b1267bbe95719cd4877d2d3cfbaf2a2f4865a" Jul 21 22:21:48 y Jul 21 22:22:33 when's the last time you did a git pull on your repos? Jul 21 22:24:26 it was there. i don't know where it is gone. i added the exports and now i think it's working Jul 21 22:25:03 no error Jul 21 22:25:15 \o/ Jul 21 22:26:01 great. thank you guys :-) Jul 21 22:26:12 np Jul 21 22:26:20 you're welcome Jul 21 22:26:20 i got some noob question. do you have time to answer them? Jul 21 22:26:56 try and see. i might be going to bed at any moment though. :P Jul 21 22:26:56 we can try. Otherwise I can point you to the ddocs Jul 21 22:27:04 ok Jul 21 22:27:47 first of all this line i added to the local.conf to built the proftpd... is this the right way to add Jul 21 22:27:49 ? Jul 21 22:27:57 yes Jul 21 22:28:06 ok Jul 21 22:28:19 it is a right way. not the only way, but nothing wrong Jul 21 22:28:35 the space matters (" proftpd") Jul 21 22:29:31 after a succesful build, i add e.g. i will also the vsftpd, how can i build a new image including all i got before and the new vsftpd without building all packages? one build takes me 4-5 hours Jul 21 22:29:33 see 5.2.1 in http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html Jul 21 22:30:05 as long as you don't change layers and a few other things, bitbake is smart enough to use what it can Jul 21 22:30:29 re-use Jul 21 22:31:01 the actual last steps of building the image will of course have to be done fresh Jul 21 22:31:05 there was always an error if i built in the same directory. but i didn't know the error anymore Jul 21 22:33:34 BlitzBlizz: rebuilding without rebuilding everything is how most builds are done when you're working on stuff. it's well-supported. Jul 21 22:33:52 and yocto figures out by itself what needs to be redone Jul 21 22:34:40 ok. i will try this after the current build. Jul 21 22:35:03 but if you add a new layer, or change branches in a layer, the metadata has changed and so a rebuild is going to happen Jul 21 22:35:38 if you are just changing what goes into an image in the existing build it shouldn't take as long Jul 21 22:35:44 ok. i will not change that much. just want to transfer some data via ftp Jul 21 22:36:44 another question. how can i change the keymap? Jul 21 22:37:22 from qwerty to qwertz Jul 21 22:37:36 28.2 in the mega manual link above Jul 21 22:38:18 eh... not much detail Jul 21 22:38:51 that's not something I've done so I'll leave it to somebody else to answer :) Jul 21 22:39:36 who will answer this? :-) Jul 21 22:43:14 here's an example: https://github.com/shr-distribution/meta-smartphone/tree/master/meta-nokia/recipes-bsp/keymaps Jul 21 22:43:30 how can i exclude packages from being build? e.g. python-dbus. i didn't need this Jul 21 22:43:42 if it built, something needed it Jul 21 22:43:54 ok Jul 21 22:43:56 bitbake does not build stuff it didn't need Jul 21 22:44:39 ok Jul 21 22:44:56 that's why the DEPENDS and RDEPENDS are there Jul 21 22:45:01 in the recipes Jul 21 22:45:20 (build time and run-time respectively) Jul 21 22:45:52 there are a lot of good books on getting started with Yocto Project... Jul 21 22:47:44 i spend the last 2 weeks with it. it's a really amazing project, but at the moment i just want to getting a simple image, which is capable of transfering data via ftp. it's for my bachelor thesis and it's not about building an yocto image :-) Jul 21 22:48:53 you could try a pre-built distribution then Jul 21 22:50:58 the problem is, i need a working mptcp kernel and for yocto i found a good tutorial Jul 21 22:54:53 well, it sounds like you are on your way to a working solution. I'm headed home. g'night. Jul 21 22:55:12 thanks again. :-) and good night Jul 21 22:55:33 you're welcome **** ENDING LOGGING AT Fri Jul 22 02:59:58 2016