**** BEGIN LOGGING AT Mon Oct 06 03:00:00 2014 Oct 06 06:32:01 hello, how do I install that graphical tool that the app builder image uses ? Oct 06 06:32:06 Hob, or Hub Oct 06 06:32:13 for generating images Oct 06 06:33:59 um... bitbake hob? Oct 06 06:34:05 yea i think so Oct 06 06:34:24 also, what does "sato" mean? Oct 06 06:34:40 if i don't have hob, how do I get a list of possible image configurations ? Oct 06 06:34:47 like , core-image-sato/minimal, etc ... Oct 06 06:35:04 sato is just the name of a generic grahical environment for demo/testing purposes. Oct 06 06:35:21 graphical environment inside the image ? Oct 06 06:35:50 you can for example run a find -iname "*-image-*" through your layers (assuming all image recipes have been named properly) Oct 06 06:36:10 yes, sato is a package group that goes *into* the iamge Oct 06 06:36:18 LetoThe2nd, i've git 'ed it all as in quick start, and modified nothing, so Oct 06 06:36:21 find should work Oct 06 06:36:22 i guess Oct 06 06:36:39 or grep for "image.bbclass" Oct 06 06:36:46 ok Oct 06 06:37:33 if i add dev tools, does bitbake create two images ? Oct 06 06:37:38 no. Oct 06 06:37:43 i want one for target, one for dev Oct 06 06:37:46 bitbake creates what you tell it to do Oct 06 06:37:53 so obviously compiler must not go to target Oct 06 06:38:14 so you have to make two image recipes, and tell bitbake to tell each of them seperately Oct 06 06:38:14 LetoThe2nd, but with Hub its probably easy quick config or not .. ? Oct 06 06:38:29 a) its called hob b) no idea, i don't use it Oct 06 06:38:36 Ok, Hob :) Oct 06 06:39:01 the standard way is that you create your product image, and then a second image that extends it for demo purposes, e.g. depends on it. Oct 06 06:39:10 s/demo/development/ Oct 06 06:39:25 I see Oct 06 06:40:45 if i would to draw it, it would be [ general big image with tools [ target image] ] . so target is a subset of general bit one :) . So i would start with the bigger one. Oct 06 06:41:13 LetoThe2nd, is it possible to generate two images same time, with two recipes ? Oct 06 06:41:43 its easier the other way round, because if you start with the bigger one you eventually have to tear apart a long list afterwards Oct 06 06:42:04 LetoThe2nd, yea, ok Oct 06 06:42:13 (at least from my experience) Oct 06 06:42:18 * LetoThe2nd is gone for a sec Oct 06 06:42:21 LetoThe2nd, as long as I back up original 'minimal' setup Oct 06 06:57:39 b00^wk: just have a look at the meta/recipes-core/images/core-image-minimal{.bb,-dev.bb} Oct 06 06:58:06 b00^wk: they give a good idea of how a dev recipe extends the base/product image for development purposes Oct 06 06:58:42 LetoThe2nd, yea, the minimal is where i thought, i start. i didn't know that extends anything, when i tried it it just had busybox in it Oct 06 06:58:58 b00^wk: the -dev extends the minimal Oct 06 06:59:06 so you can see the general mechanism Oct 06 07:13:09 good morning Oct 06 07:13:17 Ah, so there is a dev already for core-minimal ? Oct 06 07:13:21 me check Oct 06 07:14:15 morning all Oct 06 07:14:56 mourns too (UMT) Oct 06 08:47:30 Hey all, anyone seen an issue building where GCC has an internal segfault? This is building an OMAP2 board under 1.5... Oct 06 09:21:17 Hm, found it. GCC needs https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/ira-int.h?view=patch&r1=191605&r2=191604&pathrev=191605 for it not to bork. Guessing this is an ubuntu 14.04 thing... Oct 06 09:22:01 For reference / google, the error it kicked up was "../../../../libgcc/../gcc/libgcc2.c:72:1: internal compiler error: Segmentation fault" Oct 06 11:11:17 can I source oe-init-build-env again ? Oct 06 11:11:25 won't loose anything ? . i had to re-login Oct 06 11:11:47 why not, its basically jsut setting a bunch of env vars Oct 06 11:12:17 i didn't check it, thought it also creates build dir Oct 06 11:12:23 not sure if it wipes it clean first :) Oct 06 11:12:38 nope, if the config files already exist they won't be touched Oct 06 11:52:09 al'right, qemu running first time on my non Build Appliance yocot .. Oct 06 11:52:10 yocto Oct 06 11:52:33 where do I modify the image size ? Oct 06 11:53:02 with Hob there was a nice little menu ... Oct 06 12:06:30 How do we include Qt when generating sdk with "bitbake my-image -c populate_sdk" ? Oct 06 12:10:52 kbouhara: does your image recipe include Qt ? Oct 06 12:28:53 mkoan: yes it does Oct 06 12:34:48 I have IMAGE_INSTALL += "\ packagegroup-core-qt4e" defined Oct 06 12:52:06 kbouhara: so -c populate_sdk does the magic Oct 06 13:23:29 mkoan: no it doesn't work for me when I install the SDK and source the environment script, If I do "which qmake" it says /usr/bin/qmake not /opt/poky/... Oct 06 13:25:19 just having Qt in your image won't make the SDK have the tools in it Oct 06 13:26:51 try adding this to your image: TOOLCHAIN_HOST_TASK_append = " nativesdk-packagegroup-qte-toolchain-host" Oct 06 13:27:59 bluelightning: ok will try it and see it does the work Oct 06 13:33:14 what could cause kernel configuration flags to disappear in the do_kernel_configcheck step? Oct 06 13:34:14 the only clue I have is from the log, which points to the missing_required.txt log file, which simply says "Required value for CONFIG_FOO not in final ".config" Oct 06 13:36:39 you can read in the machine-config log the steps leading to it Oct 06 13:37:15 it is maybe reset by some other fragment/feature? Oct 06 13:40:22 thanks, where's the machine-config log? Oct 06 13:41:05 in the same dir under meta where required.txt is Oct 06 13:41:49 it is -defconfig in my case Oct 06 13:42:23 where do I get the (desired) max size of the target hdd image ? Oct 06 13:42:35 (I'm away from build machine, can't check precisely right now) Oct 06 13:42:53 i found IMAGE_ROOTFS_SIZE, but don't see hdd img size Oct 06 14:12:16 where does the bitbake binary go, I'm looking for it. I can run it through makefiles but not from the commandline :) Oct 06 14:13:37 or I suppose I am running bitbake somehow because I can produce images through Yocto :P Oct 06 14:21:22 found it, but Oct 06 14:22:32 ERROR: An uncaught exception occured in runqueue, please see the failure below: Oct 06 14:33:09 bitbake can't open runqueue.py Oct 06 14:37:53 xerent: what are you attempting to do? Oct 06 15:32:50 bitbake linux-yocto -c kernel_configcheck -f Oct 06 15:32:57 from build folder Oct 06 15:33:52 xerent: after sourcing oe-init-build-env ? Oct 06 15:34:56 don't know exactly, but I have built complete images using that kernel Oct 06 15:35:12 based on linux-yocto_3.10.17.bb Oct 06 15:39:10 I'm confused Oct 06 15:39:19 so am I, but I think I know what you're getting at Oct 06 15:39:25 and yes, I'm missing something Oct 06 15:39:26 surely you know if you have run oe-init-build-env within the current shell or not? Oct 06 15:40:01 and the answer to that question is "no" because I didn't know about it Oct 06 15:40:30 but looking at the Makefiles I can figure out what you're talking about Oct 06 15:42:35 OK, now I got it working, thanks Oct 06 15:50:41 though it gave me no more useful information, I'm trying to find out why my "CONFIG_REGMAP=y" is set to "" but the logs are most unhelpful Oct 06 15:57:58 how is the final config assembled? by which fragments? Oct 06 15:59:16 previously you found missing_required.txt Oct 06 15:59:29 check in the same dir, read it all ;) Oct 06 16:00:16 here under 'meta' subdir are the artifacts produced by yocto kernel tools Oct 06 16:03:58 I thought I had read it all, if I grep all the files for the config flag I only get the message that 1. it's included in the config going in, from my fragment, but 2. not included in my final .config Oct 06 16:04:07 and inbetween, I've found no reference to the darn thing :) Oct 06 16:16:20 how did you add your fragment? Oct 06 16:17:19 from files/ folder in recipe folder I added regmap.cfg, and Oct 06 16:17:42 in recipe .bbappend file I added SRC_URI_append_machinename = " file://regmap.cfg" Oct 06 16:18:01 and is your fragment processed? Oct 06 16:18:03 RP: any tips for diagnosing sstate reuse problems when neither bitbake -S printdiff nor bitbake-whatchanged show any delta whatsoever? Oct 06 16:19:25 ant_work: I think so, the same thing worked fine for other configuration flags, such as when I set CONFIG_INPUt_stuff Oct 06 16:20:52 see, there are cdases where you might want to use an .scc and set i.e. kconf hardware yourfrag.cfg Oct 06 16:21:50 setting it as hardware fragment will preserve it Oct 06 16:22:06 o_O Oct 06 16:22:17 I'm sorry but I'm away of my pc and cannot help you much Oct 06 16:22:31 however you should find fine examples in the manual Oct 06 16:22:38 (s) Oct 06 16:22:45 I'll look for that Oct 06 16:22:46 :) Oct 06 16:22:59 ...or a very comples example of mine... Oct 06 16:23:15 see this and its dir Oct 06 16:23:17 http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend Oct 06 16:24:17 the machines using feature-top.scc are fully composed by fragments Oct 06 16:24:32 the ones using 'defconfig' are kept unchanged Oct 06 16:24:46 (that was explaining it in a few words...) Oct 06 16:30:27 kergoth: resort to bitbake-diffsigs ? Oct 06 16:33:26 hmm, yeah, might be best Oct 06 16:35:48 maybe someone can help.. where [code wise] does the system compress (or create the image) from the IMAGE_ROOTFS after or part of the do_rootfs command? Oct 06 16:39:31 fray: definitions in meta/classes/image_types.bbclass, code that reads them in meta/lib/oe/image.py Oct 06 16:39:54 I've been looking through oe/image.py and can't figure out where the connection is between the IMAGE_ROOTFS and the output.. Oct 06 16:40:13 I'm trying to make the system do this action against another directory (not IMAGE_ROOTFS) as part of the rootfs process... Oct 06 16:40:45 in the old code, [pre-python] you could do this within the IMAGE_POSTPROCESS_CMD... [still happens to work here], but I'm having to manually run the tar and such commands.. Oct 06 16:40:51 I'd rather re-use what teh system is already doing Oct 06 16:41:56 fray: see _get_imagecmds Oct 06 16:42:13 that grabs the values defined in image_types.bbclass Oct 06 16:42:41 so is that the for fstype_group in fstype_groups? Oct 06 16:44:03 ok.. and then it just uses the IMAGE_ROOTFS as passed into the function.. Oct 06 16:45:18 kergoth: when you do figure it out, can you document a test case as a bug please? Makes it great to try and improve printdiff Oct 06 16:45:22 ok.. I think I'm getting it now.. so the 'create' in image.py, gets back a set of image cmd groups, which can then be run in paralle (provided it's allowed).. and the commands themsevles know how to read the IMAGE_ROOTFS, so it's never passed through the functions.. Oct 06 16:45:23 ok Oct 06 16:46:02 fray: right Oct 06 16:46:29 that connection is what I was missing.. thanks Oct 06 16:46:59 fray: you could cheat and use a copy of the datastore and set IMAGE_ROOTFS etc. to whatever you want it to be Oct 06 16:47:01 so likely the only way for me to reuse that would be t change the definition of IMAGE_ROOTFS (temporarily) and then call through at that point Oct 06 16:47:44 right, that's basically the same thing, except modifying a copy of the datastore is going to be less fragile Oct 06 16:47:56 thats what I'm trying to figure out now.. would I have to change self.d (temporarily) then? what I don't see is what value of 'd' is used by the bb.utils.multiprocessingpool / pool.impa Oct 06 16:47:59 'er.. pool.imap Oct 06 16:49:02 (what I'm working on is a parallel 'debug filesystem' that only contains the associated -dbg package contents...) that way you end up with a product and 'debug' filesystem.. if you want to merge them you can debug on the target.. Oct 06 16:49:26 I have generation working (I think) Oct 06 16:49:27 [mhatle@msp-dhcp23 1.0-r0]$ du -s rootfs* Oct 06 16:49:27 6948 rootfs Oct 06 16:49:27 89304 rootfs-dbg Oct 06 16:49:55 but it's exporting them out thats tricky.. and due to us moving all of this into the image.py, I'm having to actually modify it.. there aren't any hooks to do this dynamicall Oct 06 16:49:56 y Oct 06 16:50:29 fray: you would not want to set self.d, no. you'll probably have to change the structure of the code Oct 06 16:50:44 pool = bb.utils.multiprocessingpool(nproc) Oct 06 16:50:45 results = list(pool.imap(generate_image, image_cmds)) Oct 06 16:50:57 it's that part that I'm trying to figure out if I can modify in some way to pass an alternative datastore.. Oct 06 16:51:42 OR if the image_cmds were expanded earlier, if so I could do it there.. Oct 06 16:51:48 perhaps: Oct 06 16:51:48 image_cmd_groups = self._get_imagecmds() Oct 06 16:52:20 ahh.. yes they were expanded there.. I see now how Oct 06 16:52:33 but they were expanded using 'self.d' as the origin.. Oct 06 16:53:42 ok.. I think I have a plan.. allow the system to pass an alternative datastoer into the _get_imagecmds()... then I can set IMAGE_ROOTFS to whatever I want temproarily without messing with self.d Oct 06 16:54:45 that reminds me, it'd be lovely to implement some form of ASSUME_RPROVIDED for this, to explictly bypass certain deps without having to force bypass all dependencies. course i don tknow if all our package managers would support such a thing, or how much work it'd be.. Oct 06 16:55:00 I agree. Oct 06 16:55:28 I'm working on generating and SDK as well, and it would be nice to throw out specific target dependencies I don't care about.. Oct 06 16:55:40 i.e. I don't want bash or perl in the SDK.. :P even if glibc says it needs them Oct 06 16:55:53 indeed Oct 06 16:55:54 we could do that before things went to python (at least for rpm) by seeding the provides file.. Oct 06 16:56:12 we hit the perl one a while back trying to add git-submodule to the buildtools-tarball (needs git-perltools) Oct 06 16:56:20 * kergoth nods Oct 06 16:56:30 i figured opkg would be similar, hack the status if necessary Oct 06 16:56:41 (my hack, for now, is to disable all of the automatic dep generation during packaging for the special SDK builds.. but that isn't exactly 'general purpose') Oct 06 16:59:52 RP: I'm hitting a situation trying to share sstate between two hosts. All the signatures are the same, only the native filenames are differnet due to the different nativelsbstring, so the native setscenes can't be run. It seems it ends up rebuilding certain target recipes from scratch after the natives get built from scratch, even though all the signatures, native and target, are the same. Any ideas on that? Oct 06 17:03:19 Of course bitbake -S and bitbake-whatchanged can't tell me why anything is building from scratch, since the signatures haven't changed. and afaik there's no detailed log of bitbake's decisions wrt sstate usage Oct 06 17:11:02 kergoth: bitbake -DDDv does log some of its decisions about sstate iirc, at least what it looks for and did/didn't find. If the sigs are the same, it has to be something in the lsbstring matching part? Oct 06 17:15:06 RP: i know the nativelsbstring doesn't match, these are two different distros. but there's no reason it couldn't reuse the target stuff, it used to, but it doesn't seem to now. Presumably after it rebuilt the natives it wanted to rebuild the bits that depended on them, but it shouldn't need to, since the checksums *and* filenames for the target sstates match up, all thats changed is some of its dependencies were built from scratch. I'll do some -DDDv Oct 06 17:15:07 builds and see if I can pick up anything useful. thanks for the assistance Oct 06 18:15:24 I'm trying to get a better understanding of linux-yocto kernel configuration. I had 3.4 working nicely for two CPUs. A vortex86 and a Geode LX2. But moving forward to 3.14 is driving me crazy. How do I figure out what the baseline is on which the fragments will be applied? More apptly, how can I choose which branch to base off of? I used to use the atom-pc which was almost exactly what both of those needed. No other patches nee Oct 06 18:15:24 ded and only a very small handful of changes via .scc Oct 06 18:29:07 we should really add a bitbake argument to exit after the runqueue is prepared and the sstates were fetched / checked Oct 06 18:29:09 ala -p Oct 06 18:55:32 Exception: File "/home/mhatle/git/oss/poky/meta/lib/oe/rootfs.py", line 90 Oct 06 18:55:32 os.rename(self.image_rootfs + '-orig', self.image_rootfs) Oct 06 18:55:32 ^ Oct 06 18:55:32 SyntaxError: invalid syntax Oct 06 18:55:39 any idea what is causing that (yes thats a line I wrote).. Oct 06 18:55:51 but I'm getting zero context as to why the system things it's 'invalid' Oct 06 18:56:52 d'oh.. missing closing ) about 5 lines up Oct 06 19:27:35 kergoth: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/debugfs&id=232acd506ec2edd5c12314ef10acb5316bd10602 Oct 06 19:27:43 thats my -second- pass at the change.. Oct 06 19:31:49 something must still not be quite right, since the ext3 image didn't get generated.. but the tar.bz2 did Oct 06 20:03:55 kergoth: thinking a bit more about it, if the natives were not available, I can see how it may then want to rebuild the targets :/ Oct 06 20:04:10 kergoth: there is probably some fine tuning of the dependencies there that could be needed Oct 06 20:26:19 I'm trying to get a better understanding of linux-yocto kernel configuration. I had 3.4 working nicely for two CPUs. A vortex86 and a Geode LX2. But moving forward to 3.14 is driving me crazy. How do I figure out what the baseline is on which the fragments will be applied? More apptly, how can I choose which branch to base off of? I used to use the atom-pc which was almost exactly what both of those needed. Oct 06 20:27:21 blloyd: genericx86 is the new atom-pc, fwiw Oct 06 20:27:34 oh but those machines are probably too special for that bsp Oct 06 20:44:43 rburton: thanks, but figured that. However genericx86 seems to have a lot more modules turned on than I had from atom-pc baseline. So I'm trying to figure out how to pick my baseline without having to compile each one and just see what the .config looks like. Oct 06 20:45:24 and trying to avoid doing a defconfig, but that defconfig is looking more and more promising. Oct 06 20:46:29 I also figured better understanding of the tools is never a bad thing. I've already tried reading the code and I wasn't able to make headway on where the base config comes from. Oct 06 20:51:09 blloyd: you want to speak to bruce really, zedd when he's on here. i think i saw holiday photos on facebook though... Oct 06 20:52:00 I can't remember if he's back tomorrow or next week Oct 06 20:53:32 oh, well. Thanks fray. I've got several xf86 driver maintainers interested in my use of their drivers in yocto-project. One actually seems interested in using it himself if I can get the rest of the bugs worked out. Oct 06 20:55:29 oh? Oct 06 20:55:34 what are you doing that's awesome? Oct 06 20:56:51 fray: did you see the "package_manager.py: ignore failed smart install with --attempt" mail you got cc'd on (oe-core) Oct 06 21:18:10 fray: looks promising, quite a bit cleaner than our approach. needs a default IMAGE_FSTYPES_DEBUGFS definition, but that's minor. it's slightly odd that we pass in the -dbg suffix into _get_imagecmds, but had to append the suffix to the various vars ourselves before calling it anyway. seems like either _get_imagecmds should handle it, or it should be handled by the caller, rather than both, but that's debatable. Oct 06 21:29:33 RP: indeed, https://gist.github.com/kergoth/3cd1c0cd6862882b3b58 seems to show this behavior. not ideal, means there's no reuse at all between host distros. too late in the cycle to do much about it, of course. i'll open a bug for post-1.7 Oct 06 21:30:27 rburton: I didn't think it was very awesome. I was kinda surprised that he was interested. However, seems Geode LX hasn't worked well with Yocto in the past. Oct 06 21:32:01 hi guys Oct 06 21:32:07 who should provide libasound_module_pcm_pulse.so ? Oct 06 21:32:56 anyone know if there is a package in yocto that provides the setterm program? Or if there is a better way to control things like screen blanking? Oct 06 21:34:31 kergoth: ah, this does explain it. THe trouble is it can't even unpack that sstate file without pseudo since the users may get messed up :( Oct 06 21:35:01 ah! that makes sense Oct 06 21:35:08 time to poke at uninative, methinks :) Oct 06 21:35:19 * kergoth has that on the todo already to play with it Oct 06 21:35:53 kergoth: well, it kind of makes sense, if it were shadow-native rather than pseudo-native but the general idea applies... Oct 06 21:36:15 i trimmed the log, it's both shadow and pseudo Oct 06 21:36:17 * kergoth nods Oct 06 21:36:19 or it were avahi:do_package which does need pseudp-native Oct 06 21:36:44 but yes, uninative is our hope here Oct 06 21:36:47 Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so Oct 06 21:36:59 anybody knows what package should provide that lib? Oct 06 21:37:29 ge Oct 06 21:37:33 whoops Oct 06 21:37:58 gebreselaisi: is it saying it can't find that module, or that module is linking to something else that doesn't exist? Oct 06 21:38:46 rburton, I do not have that library in my rootfs Oct 06 21:39:16 and the rror is that from above: Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so Oct 06 21:39:29 so I guess it means that it cannot find the module Oct 06 21:39:49 I've googled around and apparently that should come from some alsa-plugins package Oct 06 21:39:54 which I do not find in yocto Oct 06 21:43:24 gebreselaisi: feel free to steal https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-multimedia/alsa/alsa-plugins_1.0.26.bb Oct 06 21:43:30 (hooray layers.openembedded.org) Oct 06 21:46:22 rburton, thanks Oct 06 21:51:24 RP: would it make sense to change populate-sysroot conflicts to use package_qa_handle_error function so it would be fatal QA error (by default) with option to disable it? Oct 06 21:52:29 RP: I think part of this problem was that normal bb.warn messages are less visible than QA messages (which are also collected in qa.log) so easy to check after the build Oct 06 21:54:47 JaMa|Off: To be honest, I don't want people to turn that on off. The issues are too nasty Oct 06 21:55:40 s/on/one/ Oct 06 21:55:43 OK, fair enough, I agree it's nasty Oct 06 21:56:30 it's last 6 failures in world builds (after including all my pending fixes), I've sent the list earlier today Oct 06 21:56:43 JaMa|Off: if it stops there and then, the issue can usually be recovered. If you continue past that you no longer know what in the sysroot is corrupted Oct 06 21:57:45 the problem is that if I go with PNBLACKLIST (to blacklist one from the conflicting duo) then I'm blacklisting something which alone is fine (unless you're building the other recipe as well) Oct 06 21:58:39 e.g. Paul won't be happy if I blacklist modphp, just because it conflicts with php and vice-versa Oct 06 22:19:24 JaMa|Off: blacklisting both php and modphp is clearly the answer, and improves the world Oct 06 22:21:40 should I send patch for oe-core to blacklist xz and lzma as well? :) Oct 07 00:00:18 Hmm, uninative doesn't like me much Oct 07 00:39:23 * kergoth smacks uninative around a bit **** ENDING LOGGING AT Tue Oct 07 03:00:00 2014