**** BEGIN LOGGING AT Thu Jan 15 03:00:00 2015 Jan 15 06:54:12 does anybody know why startx does not work in yocto. I have core-image-sato image Jan 15 09:37:17 dRbiG: there is www.oe-lite.org Jan 15 09:38:04 morning all Jan 15 09:41:24 dRbiG: to answer your question: "are there any simpler alternatives to yocto?" Jan 15 09:45:56 kimrhh: will definitely check it out. thank you Jan 15 10:49:28 dRbiG: #oe-lite on freenode Jan 15 11:00:12 chankit: core-image-sato should start x automatically Jan 15 11:08:37 bluelightning: hi - my image recipe is pulling in "kernel-dev" package which bloats the image hugely. I have not explicitly requested it. but i understand that some package may rdepend on it. I have tried PACKAGE_EXCLUDE = "kernel-dev" in my local.conf but it doesn't work. any clues? Jan 15 11:25:11 anyone please, how to get rid of kernel sources pulled in via 'kernel-dev' package into an image, Jan 15 11:33:49 darkhorse_: check the dependencies and find out what pulls it in, instead of trying to fix just the symptoms Jan 15 11:35:04 darkhorse_: that is unusual, so there must have been a reference added to it in your configuration - what have you added to IMAGE_INSTALL / (EXTRA_)IMAGE_FEATURES ? Jan 15 11:35:54 LetoThe2nd: i tried bitbake -u depexp -g to see where it is comming from. but it doesn't appear in there Jan 15 11:37:31 darkhorse_: hm. Jan 15 11:38:27 bluelightning: my IMAGE_INSTALL contains a number of packages including kernel modules Jan 15 11:41:03 bluelightning: my EXTRA_IMAGE_FEATURES is emply Jan 15 11:59:59 darkhorse_: it's a long shot, but are any of the modules you are enabling in your configuration named ending in -dev ? Jan 15 12:00:10 (kernel modules, that is) Jan 15 12:07:02 200 tasks left and I'll have another image to test Jan 15 12:10:33 bluelightning: in my image:do_rootfs() log i see quite a few such messages: kernel-dev: unsatisfied recommendation for kernel-module-ipt-reject-dev Jan 15 12:11:11 bluelightning: mind you that I have PACKAGE_EXCLUDE = "kernel-dev" in my local.conf when this message is generated Jan 15 12:42:30 ok... it broke on kernel build. reading the massive error message i think my 'core-image-minimal' built and installed a linux-dummy kernel, so now my bitbake linux-yocto fails to install :/ Jan 15 13:16:17 dRbiG: can you pastebin the error? Jan 15 13:16:37 darkhorse_: but do you have kernel modules enabled that have -dev at the end of their name? Jan 15 13:18:28 bluelightning: nvm, i broke it completely Jan 15 13:25:22 bluelightning: No, i don't have modues that have -dev at the end. what surprises me is that why it is not showing the dependency chain when i use the depexp command Jan 15 13:25:32 is there a way to tell bitbake to build only stuff that is actually needed for the image? i get 13gb worth of ./tmp to build a 11mb tar.bz2 rootfs, and it takes 4 ~ 6 hours to churn out Jan 15 13:26:13 hi guys. there wouldn't happen to be anyone here with experience or interest in porting Linux to Nintendo 64, would there? Jan 15 13:28:04 darkhorse_: this is a runtime dependency and may not show if the dependency is added dynamically at packaging time Jan 15 13:29:45 darkhorse_: one way to find this is to enable buildhistory and look at the dependency graphs produced for the image itself: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#using-build-history-to-gather-image-information-only Jan 15 13:30:21 dRbiG: broadly speaking it does only build things required for the image by default Jan 15 13:31:52 heh, i need a break from this Jan 15 13:32:41 i'm reading that it's commonplace to boot a modern linux system with 4 or 8 MB of total RAM, right? Jan 15 13:32:55 and about 8MB compressed filesystem image Jan 15 13:34:36 bluelightning: i actually have buildhistory turned on. could you please send your last message again. my browser just crashed :( Jan 15 13:43:24 hi..startx does not work but init 5 does. May I know why? Jan 15 13:50:06 dtm: 8m compressed filesystem are not much a piece of art, but 8 or even 4m ram will need some consideration. Jan 15 13:57:15 darkhorse__: ah, if you do then have a look at the buildhistory/images////depends.dot file to see if there's a dependency on kernel-dev Jan 15 13:57:22 ok, i'm not giving up yet Jan 15 13:57:42 chankit1: not sure, but perhaps something to do with not having a display manager in our default configuration? Jan 15 14:01:16 bluelightning: thanks found it although not sure if i understand why - I will spend sometime to figure out before bothering you again :) Jan 15 14:01:44 darkhorse__: I don't mind... if it's the system doing something unexpected then we certainly ought to try to fix that Jan 15 14:05:05 bluelightning: owh..okay....will dig in the direction of display manager. Thanks Jan 15 14:06:53 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/160/steps/BuildImages/logs/stdio Jan 15 14:17:49 ok, fresh poky here; i want to build for x86 with tune-c2 - should i copy genericx86.conf from meta-yocto-bsp to e.g. oldx86.conf and edit that? Jan 15 14:18:21 tune-c3* Jan 15 14:18:53 the amount of files everywhere is rather overwhelming Jan 15 14:26:39 rburton: I never say it; please report an issue and assign it to Luo Jan 15 14:27:02 rburton: he can pass it over to the QroIQ team Jan 15 14:27:04 otavio: will do, thanks Jan 15 14:29:03 bluelightning: previously i had do_package[noexec] = "1" in my kernel recipes. Hence I was not seeing this problem whereby kernel-dev package is being pulled into the image. by disabling do_package() it still works okay Jan 15 14:29:48 darkhorse__: hmm, I'm not sure that by itself a good idea Jan 15 14:30:01 bluelightning: however, do_package_setscene() fails if I disable do_package() Jan 15 14:30:27 right, that's the kind of thing I would have expected Jan 15 14:31:20 can you explain what you're attempting to do? Jan 15 14:32:49 otavio: fwiw, debian saw the same error and resolved it by not building uboot on ppc. Jan 15 14:33:09 otavio: not a workable solution for us, but its not a problem specific to us :) Jan 15 14:34:17 bluelightning: i appreciate that it is not ideal but i am just trying to get to working state first and then incrementally bring in perfection Jan 15 14:35:15 bluelightning: at the moment, i don't need packaging system at all....so the QUESTION is, shall i disable do_package_setscene() too? Jan 15 14:36:11 darkhorse__: I would probably have to look into that, I don't know that anyone has considered turning that off for the kernel up to now Jan 15 14:37:06 bluelightning: okay - thanks Jan 15 14:37:30 bluelightning: i will try that anyway and update you Jan 15 14:38:43 why don't you just build using bitbake -C it'll avoid further tasks (such as do_package) Jan 15 14:39:23 'er.. no it's be -c in this case.. Jan 15 14:41:01 hmm, wasn't aware linux kernel has a buildep on python2.7.3 Jan 15 14:46:03 dRbiG: I believe kconfig ships a python script, hence the system tries to ensure a python package is produced Jan 15 14:46:54 wanted a bannana got the whole jungle Jan 15 14:47:00 fray: the problem with that approach is that if you then have to replicate kernel:do_xxx() in all DEPENDS= statements Jan 15 14:52:06 mhm, i guess all this makes some sense if i were building for some exotic arch Jan 15 15:46:57 Hello, i'm new to yocto and I'm trying to add meta-ivi in my build, during build I'm facing the following error : DEBUG: Executing shell function do_patch Jan 15 15:46:57 | fatal: A branch named 'meta-temp' already exists. Jan 15 15:46:57 | [ERROR]: git checkout -q -b failed Jan 15 15:46:57 | ERROR. Could not locate meta series for qemux86 Jan 15 15:46:57 | ERROR: Could not apply patches for qemux86. Jan 15 15:46:59 | ERROR: Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto) Jan 15 15:47:01 | WARNING: exit code 1 from a shell command. Jan 15 15:47:03 . Can someone tell me a bit about what's going on ? Thank you Jan 15 16:07:53 bluelightning: it turns out that you can't disable do_package_setscene() . i set its noexec flag to "1" but it chooses to run anyway :( Jan 15 16:08:57 darkhorse__: yeah setscene tasks are handled in a different way Jan 15 16:13:48 bluelightning: does that mean i can't disable them? Jan 15 16:14:19 darkhorse__: not by setting noexec, no Jan 15 16:14:45 darkhorse__: you could try just stubbing out do_package (i.e. redefining it as an empty task) rather than setting noexec Jan 15 16:14:52 no guarantees that will work, but you can try it Jan 15 16:16:09 dpavel: IIRC, when building a "yocto style" kernel, it checks out the git repository and then creates a temporary branch to apply all the patches. Jan 15 16:16:38 dpavel: so, if the branch already exists (e.g. it's in the upstream repository or somehow in your local repository), it's an error. Jan 15 16:18:24 gabrbedd: Thank you for the info, I'll look into that. Jan 15 16:39:11 tell me i'm wrong: it seems like bitbake builds a package, then does rpmbuild that builds it *again* in order to package it? Jan 15 16:39:51 dRbiG: what suggests that to you? Jan 15 16:40:30 gabrbedd : How can I locate that meta-tmp in upstream repo. In my locals I didn't find anything ... Jan 15 16:40:44 dRbiG: we do call rpmbuild to build an rpm, but that's only because that's the standard way to do that - there's no compilation at that step as there would be in a normal rpm-based distro Jan 15 16:41:43 dRbiG: does the package use scons? scons is notorious for that crap. Jan 15 16:42:39 dpavel: The "quick" way is to do `bitbake -c devshell' Jan 15 16:42:57 dpavel: That should take you to the source code folder that bitbake builds on, and you can inspect it there. Jan 15 16:48:35 I am getting parsing errors when using linaro layer with latest dizzy OE-Core it has started after the gcc-source backport into dizzy Jan 15 16:48:39 bluelightning: yeah, it didn't like it. threw some nasty Lex errors at me Jan 15 16:48:46 gcc-crosssdk_linaro-4.8.bb: Failure expanding variable do_fetch: ShellSyntaxError: LexToken(TOKEN,"'do_fetch',",0,0) Jan 15 16:48:49 followed by: LexToken(TOKEN,"'stamp-base'",0,0) LexToken(RPARENS,')',0,0) LexToken(NEWLINE,'\n',0,0) LexToken(TOKEN,'d.delVarFlag',0,0) LexToken(LPARENS,'(',0,0) Jan 15 16:49:09 I am stumped a bit on this Jan 15 16:49:16 what could be missing Jan 15 16:51:07 RP ^ Jan 15 16:51:36 bluelightning: :) i am a bit stuck now...all the output i need is just there i can see it. it does generate the kernel image and deploys it as expected. Jan 15 16:52:22 khem: we changed the gcc code not to use stamp-base Jan 15 16:52:35 khem: that error is coming from the parser, there is something in there it can't understand Jan 15 16:53:04 khem: in fact it looks like the shell parser is trying to parse python code Jan 15 16:53:43 darkhorse__: don't know I'm afraid; as I hinted at earlier you're on slightly untested ground - perhaps you might need to declare the stub as a python function though Jan 15 16:55:48 RP: yes I saw the changes but couldnt relate to why this would happen Jan 15 16:56:24 khem: did a function change python -> shell or vice versa with an append? Jan 15 16:56:49 this is what the recipe is Jan 15 16:56:50 https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-linaro-toolchain/recipes-devtools/gcc/gcc-cross_linaro-4.8.bb Jan 15 16:57:01 let me check Jan 15 16:57:37 bluelightning: using "python" keyword or "def" ? Jan 15 16:58:37 darkhorse__: python Jan 15 17:04:23 bluelightning: Failure expanding variable do_package: SyntaxError: invalid syntax (, line 2) - it suggest i have a syntax error where i put a colon inside the body of the stub Jan 15 17:12:16 bluelightning: looking at the bitbake options there's a "--no-setscene" option that can be passed to bitbake. i wonder if one can some pass setscene task names that sould be run? Jan 15 17:37:35 RP: nothing I see Jan 15 17:37:44 that defines a function Jan 15 17:38:02 the recipes override the SRC_URI pretty much and rename PV Jan 15 17:38:06 thats all Jan 15 17:38:19 all: a general question about sharing sstate-cache: in a team environment, i understand that each task within each recipe has its own checksum. If your task's checksum does not match it will be re-run and then your modified task will also become part of the sstate-cache. this means cache will carry on growing indefinitely and its growth rate will be proportional to the activity level and team size? Jan 15 17:39:01 darkhorse__: see sstate-cache-management.sh in oe-core/scripts/ Jan 15 17:39:28 of coures, tehre are other ways of managing it. in the past i've kept the cache on a mount with atime enabled and periodically removed anything that hadn't been accessed in more than a week Jan 15 17:43:50 kergoth: thanks :) so what is the recommended strategy: have one sstate-cache per x number of developers, one sstate-cache per build machine, or just one common sstate-cache for everything including release builds? Jan 15 18:25:33 if i do `bitbake linux-yocto`, then `bitbake core-image-minimal`, then go around and modify the kernel to actually work, then redo `bitbake linux-yocto` - will that include the modules in the rootfs image, or do i have to redo `bitbake core-image-minimal`? Jan 15 18:26:32 and if i have to redo - will it be nice enough to just repackage the modules or will it wipe and go compiling everything again for 6 hours? Jan 15 18:35:24 Hi all -- is it possible to have a single recipe build and install two separate automake projects? Jan 15 18:36:09 I have a git repo that contains several separate projects, and I would like to be able to deploy them both without cloning the repo multiple times. Jan 15 21:06:18 ok, i did build something that boots further; now i've got a new problem Jan 15 21:16:06 well, now it can actually see my via ata controller, but readin root is one big i/o error Jan 15 21:18:48 i have an ata-cf 'converter' there, which worked fine with: windows xp, archlinux and netbsd Jan 15 21:26:14 anyways - thank you all for support Jan 15 21:29:24 my impression is yocto is the autotools for embedded linux Jan 15 21:57:26 heh **** BEGIN LOGGING AT Thu Jan 15 22:43:37 2015 **** BEGIN LOGGING AT Thu Jan 15 22:48:32 2015 **** BEGIN LOGGING AT Thu Jan 15 23:02:32 2015 Jan 16 00:03:12 Hello everyone, I may have found a bug in gpsd recipe. Its udev rule (http://bit.ly/1uaJr1l) executes a file name "gpsd.hotplug.wrapper". However the wrapper file is nowhere to be found in the recipe. Jan 16 00:03:36 Can someone pleaes take a look? I may be missing something. Perhaps udev is that magical **** ENDING LOGGING AT Fri Jan 16 02:59:58 2015