**** BEGIN LOGGING AT Mon Dec 16 03:00:01 2013 Dec 16 07:37:59 hi all i have written a script file,i just want to add that in rootfs in /opt/sdk72xx/resources path so i added that in init file please see http://pastebin.com/v6H3zJVp but there is no files in /opt/sdk72xx/ directory can you help me Dec 16 08:38:44 good morning! when trying to depend on libgfortran, i run into "ERROR: libgfortran was skipped: libgfortran needs fortran support to be enabled in the compiler" Dec 16 08:42:17 i tried to extend poky.conf with FORTRAN = ",f77" but that also doesn' seem to do the trick Dec 16 08:51:45 ndec: moinmoin Dec 16 08:52:00 LetoThe2nd: morning! Dec 16 08:52:23 ndec: remember our discussion about .conf vs. .bb? :) Dec 16 08:52:38 yes. Dec 16 08:53:01 i'm trying to depend on libgfortran, but somehow getting fortran support built in is.. not that easy. Dec 16 08:53:19 i subclassed poky and set there FORTRAN ?= "fortran" Dec 16 08:53:44 what do you mean by subclassed? Dec 16 08:54:12 now when i do bitbake -e core-image-minimal | grep ^FORT i get the variable, but for bitbake -e libgfortran the var doesn't seem to be there. Dec 16 08:54:52 sublassed: http://paste.ubuntu.com/6582543/ Dec 16 08:55:17 is this variable needed for libgfortran? Dec 16 08:55:39 disclaimer: i am not at all familiar with adding fortran in OE ;-) Dec 16 08:55:50 well libgfortran has this: Dec 16 08:55:52 python __anonymous () { Dec 16 08:55:52 f = d.getVar("FORTRAN", True) Dec 16 08:55:52 if "fortran" not in f: Dec 16 08:55:52 raise bb.parse.SkipPackage("libgfortran needs fortran support to be enabled in the compiler") Dec 16 08:55:56 } Dec 16 08:56:21 which sounds reasonable. but i don'T get why the env var is there one time, and not the other time. Dec 16 09:00:56 LetoThe2nd: it seems that you should do FORTRAN = ",fortran". it's used in a comma separated list. not sure if that will solve your problem... but it's still a step forward.. Dec 16 09:01:09 any ideas? i though .conf always should hit the environment? Dec 16 09:02:23 even stranger. i set FORTRAN = ",fortran" in my distro file. Dec 16 09:03:25 also, i found this in local.conf.sample.extendend: Dec 16 09:03:25 # Enabling FORTRAN Dec 16 09:03:25 # Note this is not officially supported and is just illustrated here to Dec 16 09:03:25 # show an example of how it can be done Dec 16 09:03:25 FORTRAN_forcevariable = ",fortran" Dec 16 09:03:26 LetoThe2nd: have you looked at local.conf.sample.extended? Dec 16 09:03:38 then bitbake -e XXX | grep ^FORT gives me for XXX->YYY: bc -> FORTRAN=",fortran", gcc -> FORTRAN="", and libgfortran -> (nothing) Dec 16 09:03:56 RP: not yet. second please. Dec 16 09:04:12 LetoThe2nd: i think i copy/pasted the relevant part above Dec 16 09:04:23 RP: what is _forcevariable? Dec 16 09:04:34 LetoThe2nd: you need all the lines there, not just the one ndec pasted Dec 16 09:04:46 ndec: Its the strongest override we have Dec 16 09:05:01 RP: Is there any chance of getting anything more into 1.5.1? I was thinking of the support for % in bbappend filenames. It is not really usable for 1.6 until it is in 1.5... Dec 16 09:05:20 RP: i see. thanks. and i see now all the other lines too.. Dec 16 09:05:53 Saur: that would be a feature backport, it wasn't in 1.5 at all Dec 16 09:06:03 good morning Dec 16 09:06:52 RP: by "other lines" you mean the libquadmath thing, right? Dec 16 09:06:52 RP: True, in a sense. But then the feature will be useless until 1.7 is released... Dec 16 09:07:30 LetoThe2nd: yes, that sounds like master Dec 16 09:08:00 LetoThe2nd: there were more lines in dora and I don't know which you're using Dec 16 09:08:13 RP: using HEAd from 25minutes ago. Dec 16 09:08:26 LetoThe2nd: then its two lines Dec 16 09:08:42 RP: ok thanks. will kick off the build and report back then. Dec 16 09:09:03 Saur: that isn't true. You can use it in any 1.6 layers going forwards from now Dec 16 09:10:25 RP: Yes, but the reason we wanted that kind of feature was so that we can use one version of our layer for both stable (i.e., dora) and master. But we cannot do that until both versions of Poky support % in bbappend. Dec 16 09:12:16 Saur: well, that doesn't change the fact that we don't backport features Dec 16 09:12:57 Saur: for example the patch that implemented it did break things Dec 16 09:13:16 RP: Fair enough. Just irritating to have to have two branches for another half year or so when there is a solution... Dec 16 09:14:37 Saur: I wouldn't recommend having one branch trying to track both anyway Dec 16 09:16:04 RP: Not sure whether it will be feasible in the long run. But at the moment the only difference for us is two small bbappends... Dec 16 09:17:39 Saur: Depends what we do in master I guess, we so sometimes make bigger changes Dec 16 09:35:09 If I add DISTRO_FEATURES = "e-wm" to local.conf (and ofc the meta-efl folder to bblayers), shouldn't the dependencies make me fetch all the efl packages ? Dec 16 09:57:10 oswin: is e-wm a valid DISTRO_FEATURES value? Dec 16 09:58:05 bluelightning, how can I know this ? Dec 16 09:58:36 Hello, good morning :-) Dec 16 09:58:49 oswin: well, what suggested to you that you should add it to DISTRO_FEATURES? Dec 16 09:58:58 morning vicenteolivert Dec 16 09:59:15 Hi bluelightning, how was your weekend? :-) Dec 16 09:59:28 vicenteolivert: not too bad, and yours? Dec 16 10:00:21 bluelightning: I went to see the Hobbit movie :P Dec 16 10:00:29 bluelightning, I thought it was the right was regarding other examples ^^ Dec 16 10:01:12 vicenteolivert: nice... I'd like to see that as well Dec 16 10:02:19 bluelightning: it's a good movie, in my opinion. Dec 16 10:02:35 vicenteolivert: well, it was made in my home country, so I'd like to think so :) Dec 16 10:02:56 bluelightning: are you from NZ? Dec 16 10:03:01 vicenteolivert: I am, yes Dec 16 10:03:14 Wow, first person I ever meet from that place. Dec 16 10:03:47 oswin: e-wm is a recipe / package name, not a valid DISTRO_FEATURES item Dec 16 10:03:55 Well..., changing the topic, does anyone can help me with this error? It fails at the point of making the rootfs: http://pastebin.ca/2508173 Dec 16 10:07:04 ant_work: is that the error you saw? ^ Dec 16 10:08:36 bluelightning, do you have some good reference for yocto beginners about recipe/distro usage and inclusion. I read the user guide, it gives a lot of general information but I feel a bit lost when I go through the several meta data, I don't know what it provides, and how or where to include the things correctly.$ Dec 16 10:12:13 oswin: well, the only real documentation we have are the manuals Dec 16 10:12:32 oswin: I'm happy to answer specific questions here though Dec 16 10:12:58 bluelightning: seesm the same as in JaMa logs Dec 16 10:13:10 ant_work: was there a workaround? Dec 16 10:13:24 I think it is fixed in master Dec 16 10:13:32 oswin: FYI, DISTRO_FEATURES select from a more-or-less set list of features that feed into options used at compile time, so you wouldn't put names of recipes or packages in there Dec 16 10:13:49 vicenteolivert: what version of the build system are you using? Dec 16 10:13:50 workaround is probably to get rid of/rename the device_table files in meta-handheld Dec 16 10:14:04 bluelightning: master (you mean that?) Dec 16 10:14:06 bluelightning, for example : what is the simplest way to add e-wm to poky distro, for a temporary test. Should I just add the package inclusion in local.conf (with IMAGE_INSTALL ?) ? Dec 16 10:14:24 vicenteolivert: ok, how recent master? Dec 16 10:14:32 bluelightning: last friday. Dec 16 10:14:44 oswin: there are a number of ways: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Dec 16 10:14:53 or to add IMAGE_DEVICE_TABLES = "" to the offended initramfs images Dec 16 10:15:33 oswin: probably the easiest way to do it temporarily would be via IMAGE_INSTALL_append = " e-wm" though yes (and don't miss out the leading space in the value) Dec 16 10:16:20 vicenteolivert: which machine are you building for? Dec 16 10:16:33 MIPS32 Little Endian. Dec 16 10:18:02 bluelightning, ok thanks. btw is it usual that the linux-yocto kernel take veeeeeerry long to fetch ? Dec 16 10:18:56 oswin: it shouldn't, no... I guess it may depend on your internet connection though Dec 16 10:19:06 vicenteolivert: oh yes I remember now Dec 16 10:19:34 vicenteolivert: you don't have meta-handheld in your bblayers.conf by any chance do you? Dec 16 10:19:50 bluelightning: Let me check. Dec 16 10:20:49 bluelightning: this is my bblayers.conf : http://www.pastebin.ca/2508245 Dec 16 10:21:14 bluelightning, I've got 100MB/s in effective, is it possible to show the DL speed or percentage ? I have no info with -DDD about this Dec 16 10:21:16 It's as is by default. I haven't changed anything. Dec 16 10:24:07 vicenteolivert: ok Dec 16 10:26:31 bluelightning: any clues? Dec 16 10:29:09 vicenteolivert: it looks like the fix for that just went in... try doing git pull Dec 16 10:31:26 Done. Dec 16 10:32:06 bluelightning: now I'm running "bitbake core-image-basic" again, and it's doing all the job again. Is that normal? Dec 16 10:32:52 vicenteolivert: likely one or more of the other changes since you last pulled changed something that means those tasks need to be re-executed Dec 16 10:33:36 bluelightning: ok. I hope it works :-p I'll let you know when it finishes. Dec 16 10:33:45 Thanks. Dec 16 10:46:03 which version of python do you use (on host) ? Dec 16 10:46:38 oswin: python 2.7.x Dec 16 10:47:27 oswin: we have buildtools-tarball for those systems that have a python version that is too old / new Dec 16 11:20:16 bluelightning, ok thanks, it was just for the case yocto was better optimized for v3 Dec 16 11:26:43 oswin: there's porting of bitbake to py3 ongoing, but it's a non-trivial codebase so the port isn't easy. Dec 16 11:30:17 bluelightning: it worked! Dec 16 11:30:23 Thank you very much. Dec 16 11:30:58 vicenteolivert: no problem :) Dec 16 11:32:09 bluelightning: but I don't understand why now it only creates a .ext rootfs image and not a .cpio.gz like the last time (I used core-image-minimal the last time) Dec 16 11:32:38 vicenteolivert: that's controlled by IMAGE_FSTYPES Dec 16 11:33:05 bluelightning: If I try to do it now, do I need to recompile everything? (I guess no...) Dec 16 11:33:24 vicenteolivert: no, it'll just re-run the image generation part Dec 16 11:33:47 _:-) Dec 16 11:44:05 bluelightning: seems that it doesn't work well... It creates an empty cpio.gz file and creates a ext3 file again. Dec 16 11:44:32 vicenteolivert: how are you setting IMAGE_FSTYPES? Dec 16 11:45:08 IMAGE_FSTYPES = "cpio.gz" Dec 16 11:45:17 That way, bluelightning. Dec 16 11:45:28 In my local.conf Dec 16 11:49:25 vicenteolivert: anything useful in log.do_rootfs? Dec 16 11:51:16 bluelightning: should that file be on my ./build/tmp/ directory? Dec 16 11:52:06 vicenteolivert: tmp/work/-poky-linux//1.0-r0/temp/ yes Dec 16 11:55:47 bluelightning: I don't see anything useful. Is there a way to for the rebuild of the image without removing the tmp/ directory? Dec 16 11:56:53 *force Dec 16 11:57:32 vicenteolivert: I don't think forcing is going to help this Dec 16 11:57:54 I tried to create an ext2 image and it creates it well. Dec 16 11:58:06 But the cpio.gz is empty. Only 4KB. Dec 16 11:58:08 right, so forcing definitely won't help Dec 16 11:58:29 did you check log.do_rootfs after building with cpio.gz in IMAGE_FSTYPES? Dec 16 12:00:12 bluelightning: I can do it again if you want. Is safe to remove the content on tmp/work/-poky-linux//1.0-r0/temp/ right? Dec 16 12:03:53 vicenteolivert: you don't need to remove that, it's just the logs and scripts that get written out every time Dec 16 12:04:41 Ok, then I'm going to run bitbake again. Dec 16 12:09:16 bluelightning: this is what I do: http://www.pastebin.ca/2508268 Dec 16 12:09:34 bluelightning: and here you have the log file: http://www.pastebin.ca/2508269 Dec 16 12:14:01 vicenteolivert: so this is strange... the text at the end suggests that there's not a lot in the image at all Dec 16 12:15:00 bluelightning: yes, but the ext3 image it's ok. Dec 16 12:15:14 $ du -hs core-image-basic-qemumips-20131216103019.rootfs.ext3 Dec 16 12:15:19 5.5M core-image-basic-qemumips-20131216103019.rootfs.ext3 Dec 16 12:18:59 vicenteolivert: I'm not sure what is happening but something is going wrong there Dec 16 12:19:07 vicenteolivert: I will try the same here after lunch Dec 16 12:19:53 bluelightning: do you know how to transform an .ext3 image to .cpio.gz? Dec 16 12:20:13 I think qemu can do it with qemu-img convert ... Dec 16 12:20:28 vicenteolivert: well, at the most basic level just mount the image and then use cpio + gzip to compress it again Dec 16 12:20:39 does anyone actually use the cpio.gz files? Dec 16 12:20:40 that shouldn't be necessary of course... Dec 16 12:21:34 rburton: it's useful to put it into a kernel as a initramfs. Dec 16 12:21:43 If feel like my yocto build is very slow. I just can't understand why a do_unpack of ncurses take more than several minutes, while CPU usage is near 15% and disk access not over a MB (both r/w). Is that a normal situation ? Dec 16 12:21:49 vicenteolivert: fair enough. Dec 16 12:22:21 oswin: no Dec 16 12:22:26 oswin: do_unpack of ncurses taking that long is very unusual Dec 16 12:22:49 do you have an idea what could be the source of this slowness ? Dec 16 12:23:01 unpack should be just extracting the tarballs. Dec 16 12:23:49 oswin: definitely just the unpack stage? can you replicate if you do bitbake ncurses -c unpack -f? Dec 16 12:24:24 I have several shell, tar and python process (running 8 tasks) but all seems be pending, they uses 0% CPU Dec 16 12:25:12 io contention? Dec 16 12:25:13 rburton, gonna try a separate build, but I think it's everything who's slow, fetch should be faster regarding my Internet access speed, build should be faster too Dec 16 12:25:35 even stopping the process with ctrl-c (once) takes 5 minutes Dec 16 12:26:35 well that's a clean stop, so depends on what's currently running. Dec 16 12:26:55 that bitbake command i said will just do the unpack of ncurses Dec 16 12:27:06 and if that's still slow you can instrument it a bit Dec 16 12:27:19 totally worth checking that your CPU isn't overheating though, if everything is slow :) Dec 16 12:28:01 or disk failing... Dec 16 12:28:20 or some other process eating I/O bandwidth Dec 16 12:29:02 as unpack is only a tar command, a disk that's having trouble finding sectors it entirely plausable Dec 16 12:29:38 rburton, (still waiting bitbake closing to test separate build) Dec 16 12:30:53 does tar temporary extract file to the system disk ? Dec 16 12:31:11 could be part of the problem, I have yocto on a secondary disk Dec 16 12:36:01 Oh I found some nasty HAL daemon making IO overhead Dec 16 12:39:03 do you have yocto on a journalized FS ? Dec 16 12:40:12 what else might be needed when depending on fortran? libgfortran seems to build, but the packages configure still fails: http://paste.ubuntu.com/6583215/ Dec 16 12:50:54 Found some useful informations here : https://wiki.yoctoproject.org/wiki/Build_Performance, running like a charm now ! Dec 16 12:50:57 thanks for your help Dec 16 12:59:15 any ideas what might be needed to link against fortan? see paste line 289 Dec 16 13:01:25 respectively, line 6699 Dec 16 13:21:48 RP: ping ^^ Dec 16 13:28:23 LetoThe2nd: first question is why is the compiler using -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu ? Dec 16 13:28:33 LetoThe2nd: all those paths look wrong Dec 16 13:29:51 LetoThe2nd: to be honest whilst I made the fortran compiler build I don't use it and I don't have much idea about how you're supposed to use it Dec 16 13:36:18 RP: i don't have much of a clue about it too, i'm just trying to cough up a recipe for R Dec 16 13:36:51 Which image is bigger, core-image-base or core-image-basic? Dec 16 13:38:49 With core-image-base I have a complain like this: http://pastebin.ca/2508290 ; with core-image-basic I don't have that message. Dec 16 13:44:07 RP: the corresponding configure.ac is here: https://svn.r-project.org/R/trunk/configure.ac Dec 16 13:46:05 LetoThe2nd: I simply don't know. Without diving into it and trying to learn how it all works I simply don't know how to help Dec 16 13:46:40 RP: ok, no worries. just wanted to give it a last try ;) Dec 16 14:29:43 HI all, I am getting: mac80211.c:21:38: fatal error: libnl3/netlink/genl/genl.h: No such file or directory Dec 16 14:29:47 where to look? Dec 16 14:30:08 I am trying to compile netsniff-ng package Dec 16 14:45:30 bluelightning: I have removed the build directory and started again, but I still having the same problem (an empty cpio.gz image). This is the full process: http://www.pastebin.ca/2508310 Dec 16 14:45:49 vicenteolivert: I didn't expect that would help Dec 16 14:48:46 bluelightning: also, I have mounted the ext3 image, and it doesn't look ok: http://www.pastebin.ca/2508313 Dec 16 14:49:32 Only /var/ and /etc/ directories with only a few files? Dec 16 14:49:37 vicenteolivert: right, that's what the log was suggesting Dec 16 14:49:51 something has gone wrong there Dec 16 14:51:22 bluelightning: and this is very weird too: http://www.pastebin.ca/2508314 Dec 16 14:52:29 vicenteolivert: that's probably sparse file stuff at work - empty space not being allocated Dec 16 14:52:40 Ahhh. Dec 16 14:52:48 Is the first time I see that :-) Dec 16 14:53:54 well, that's my only idea as to why you'd see that behaviour Dec 16 14:54:06 bluelightning: do you have any idea to fix this? Dec 16 14:58:48 And this is another problem when I try to use core-image-base and core-image-sato: http://www.pastebin.ca/2508315 Dec 16 15:00:03 It tries to pull in linux-yocto and then I have two kernels, linux-yocto and linux-dummy. Dec 16 15:31:58 Is there a way to know the target architecture inside a nativesdk package e.g. cortexa9-vfp-neon-yocto-linux-gnueabi ? Dec 16 15:43:00 vicenteolivert: ok I think I have reproduced your problem here Dec 16 15:44:27 Ok, really confused in migrating from Bernard-5.0.1 to Dora-10.0.0. I have a working system under Bernard, Dora is weird. If I build the 'core-image-sato', I get an /etc/modprobe.d, but 'core-image-minimal' does not produce that. Dec 16 15:45:02 What I cannot figure out, yet, is what package group it is in sata that allows the use of kernel modutils (/etc/modprobe.d). Dec 16 15:45:47 It looks like something to do with meta/classes/kernel.bbclass ?? Dec 16 15:46:24 What is trigging 'core-image-sato' to make the needed '/etc/modprobe.d/' directory in the final image? Dec 16 15:47:01 see buildhistory, it should have detailed information about the contents of the image, including package lists and package file lists, should be able to track it down there Dec 16 15:47:12 otherwise yo ucould just boot core-image-sato and query the package manager to see what owns /etc/modprobe.d Dec 16 15:48:09 kergoth: elaborate on the package manager query please? Any docs on that? It is something new. Dec 16 15:48:46 kergoth: what would be an example of pacakge manager query? e.g. 'rpm -ql XXX' Dec 16 15:48:48 depends on what package manager you're using Dec 16 15:48:56 default Dec 16 15:49:34 So, I guess that is 'smart'? Dec 16 15:49:56 smart is the yum replacement, it doesn't replace rpm Dec 16 15:50:00 rpm is still the underlying package manager Dec 16 15:50:23 iirc you'd want rpm -qf or something, i'd double check the rpm documentation, i don't use rpm distros very often Dec 16 15:50:32 ok Dec 16 15:50:36 kergoth: thanks Dec 16 15:51:11 kergoth: once I get a handle on who is producing the directory, I can grep my way back. Dec 16 15:51:59 bluelightning: really? Then is not *my* problem, right? Dec 16 15:54:40 vicenteolivert: no, I didn't think it was ;) Dec 16 15:54:47 vicenteolivert: I still can't quite tell what's causing it Dec 16 15:58:08 bluelightning: anyway, there is an important problem on Yocto that developers need to fix; the recipe linux-yocto (which I guess is a very important recipe) seems to mix the endianess when you try to build it on Little Endian (at least on MIPS32 Little Endian). Dec 16 15:58:24 I have a custom bsp layer included, and the bbappend is applied, however the defconfig is that of the original meta-fsl-arm/recipes-kernel/linux/linux-imx-*/mx6q/defconfig and not from my overlayed layer. if anyone has insight as to what I missed .. I would appreciate it. Dec 16 15:58:31 http://ix.io/9op http://ix.io/9oq Dec 16 15:58:43 vicenteolivert: if you could file a bug about that explaining the problem that would be very much appreciated Dec 16 15:59:36 bluelightning: yes I can. Mind to give me the Yocto's bugzilla url please? Dec 16 15:59:45 vicenteolivert: bugzilla.yoctoproject.org Dec 16 15:59:52 Oh, easy. Dec 16 16:01:24 WarheadsSE: unfortunately meta-fsl-arm has put its defconfig file there into a directory that means it will be picked up ahead of yours (due to the order of OVERRIDES) Dec 16 16:01:40 WarheadsSE: I don't think they should be doing this Dec 16 16:02:09 WarheadsSE: to work around it you can put your file in a subdirectory named with the machine name (as an example) Dec 16 16:02:19 otavio: ^ Dec 16 16:03:48 vicenteolivert: try commenting out the PACKAGE_EXCLUDE line Dec 16 16:03:50 bluelightning: thanks. Dec 16 16:03:55 vicenteolivert: see if that fixes it Dec 16 16:04:35 bluelightning: so, mx6q/imx6qmalak .. as an example Dec 16 16:04:48 or should it be just the machine Dec 16 16:04:56 WarheadsSE: no, it would just be imx6qmalak assuming that's the MACHINE value Dec 16 16:05:05 K Dec 16 16:10:36 vicenteolivert: do you set explicitely PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" Dec 16 16:10:50 ant_work: no. Dec 16 16:11:03 ah, ok, then the -dummy Dec 16 16:11:23 Yes, I set this: PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Dec 16 16:11:46 do you really want that? Dec 16 16:13:31 ant_work: yes, because two reasons. The first one is that I don't need the kernel Yocto will build for me; the second one is that linux-yocto fails to build for my target arch (mips32 little endian). Dec 16 16:15:14 vicenteolivert: we don't have a mips le machine defined by default, so you need to tell the linux-yocto kernel to build the right BSP. what did you use ? just the existing qemumips ? Dec 16 16:16:00 zeddii_home: yes, just the existing qemumips. Dec 16 16:16:16 well, not surprisingly that's big endian. Dec 16 16:16:17 But I set this in my local.conf: DEFAULTTUNE = "mips32el" Dec 16 16:16:23 that's usespace. Dec 16 16:16:28 you need a BSP. Dec 16 16:17:19 zeddii_home: so..., I need to copy the existing qemumips machine to qemumipsel, and then modify it to make it little endian? Dec 16 16:18:02 yes, it should be pretty much a one liner. sec, let me check something. Dec 16 16:20:14 zeddii_home: ok Dec 16 16:21:37 vicenteolivert: so it seems we've already logged a bug for the underlying problem: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5311 Dec 16 16:22:01 * zeddii_home can't tell if anyone is around with the hit of exit/enters Dec 16 16:22:01 regardless, if you copy the existing qemumips.conf and change the machine to "qemumipsel" linux-yocto will dig up the little endian config. Dec 16 16:22:13 bluelightning: I was trying to register a new account on that bugzilla but seems that I can't receive emails right now :S Dec 16 16:22:31 zeddii_home: really!? That's very easy then. Dec 16 16:22:55 it gets built infrequently, so I'm keen to hear how it goes. I'll be around to assist. Dec 16 16:22:55 zeddii_home: I'm going to try it. If that's correct, I will not need the linux-dummy and the PACKAGE_EXCLUDE. Dec 16 16:23:14 zeddii_home: thank you very much. Dec 16 16:23:48 Bug 5311: normal, Medium+, 1.5.1, paul, WaitForUpstream , can't use PACKAGE_EXCLUDE with an ipk image based Dec 16 16:30:14 zeddii_home: before trying it, just a quick question. When I create the BSP with this command "yocto-bsp create ", should that arch be "mips", or "mipsel" instead? Dec 16 16:30:47 If I list the arches, only mips is avaiable. Dec 16 16:30:52 *available Dec 16 16:31:11 I'd say mipsel, but since we don't have an "exposed" mipsel machine, the BSP script likely can't handle it. Dec 16 16:31:29 so go with mips, and edit the userspace tune and machine name to what I mentioned. Dec 16 16:33:05 zeddii_home: yeah, I have already copied the qemumips.conf to qemumipsel.conf, and I still having DEFAULTTUNE = "mips32el" in my local.conf Dec 16 16:34:04 bluelightning_: :/ no luck, mv mx6q imx6qmalak; bitbake -c cleanall linux-imx; bitbake linux-imx Dec 16 16:34:07 same defconfig .. Dec 16 16:41:06 bluelightning_: about the bug of "PACKAGE_EXCLUDE with an ipk", I'm using ipk because I read somewhere that it pulls less dependences. I don't mind to use rpm instead... Anyway, now I have removed the PACKAGE_EXCLUDE, but is worth knowing that such a bug exists. Thank you :-) Dec 16 17:04:21 zeddii_home: wrt linux-yocto_3.12: when? Dec 16 17:04:54 * ant_work awaiting to drop many patches from layer Dec 16 17:05:49 I've updated the -dev kernel to 3.12.x already, but for Yocto 1.6 we were going to head to 3.13, so I hadn't planned on dropping a "versioned" linux-yocto for 3.12. I expect to have 3.13 out shortly, we are working on integrating the new kernels into the master under test builds before I throw the switch, so 3.12 has stayed longer to keep some stability .. long answer :) Dec 16 17:06:54 zeddii_home: heh, I have the patches in 3.10 and in -dev ;) 3.13 sounds even better Dec 16 17:07:21 * zeddii_home isn't superstitious about 13, so it should be a good one ;) Dec 16 17:10:29 oh, btw, I've 'discovered' that to use the shrunk defconfig I need alldefconfig Dec 16 17:10:33 # re-expand the defconfig produced by 'make savedefconfig' Dec 16 17:10:33 KCONFIG_MODE = "--alldefconfig" Dec 16 17:10:50 I did that in linux-yocto-tiny Dec 16 17:11:31 linux-yocto-tiny_kexecboot_3.10.bbappend to be precise Dec 16 17:14:07 zeddii: logically, isn't? I've overlooked it for so long... Dec 16 17:18:34 ha :) indeed Dec 16 17:24:51 bbl Dec 16 17:27:52 kergoth: ok, I see, packagegroup-XXX replaces the old task-XXX, got it. Dec 16 17:52:07 writing my first recipe to compile a out of the shelf library (fastcgi) following the example there : http://www.openembedded.org/wiki/How_to_create_a_bitbake_recipe_for_dummies I am getting ./configure not found but it is available in the build directory. the build directory has the following files : fastcgi-2.4.1, fcgi-2.4.1 <- library sources, temp, license_destdir. where should the directory Dec 16 17:52:07 be ? Dec 16 17:56:07 weebet: that sounds like you need to set S to point to the actual dir where the source has been extracted (I'm guessing S = "${WORKDIR}/fcgi-${PV}" ) Dec 16 18:00:17 Hello bluelightning. I tried this, and I also tried ${WORKDIR}/fcgi-${PV}/fcgi-2.4.1-SNAP0311112127 and no luck with this. I understand the the subdirectory must be named like the SRC_URI:// name ? Dec 16 18:00:43 weebet: it's entirely dependent on the structure of the archive you're downloading Dec 16 18:00:49 weebet: i.e. it's dictated by upstream Dec 16 18:01:26 * bluelightning has to go Dec 16 18:02:28 zeddii_home: thank you soooo much. It's working now! Dec 16 18:02:47 bluelightning: goodbye, see you tomorrow. And thanks for your help :-) Dec 16 18:02:53 vicenteolivert: np Dec 16 18:11:59 I'm going home to. See you tomorrow! Dec 16 18:12:03 *too Dec 16 18:26:15 hi, why is Yocto not checking the linux kernel out as a git repository? Dec 16 18:26:25 it is getting painful to work on a Linux kernel patch with Yocto this way. Dec 16 18:32:32 why is Yocto not rebuilding my kernel code after some modification in ./tmp/build? Dec 16 18:38:49 lpapp: eheh, that's funny! a couple of weeks/months ago, i remember you were complaining when yocto was checking out from git instead of using tarball. ;-) Dec 16 18:40:07 also, i think that linux-yocto is using git by default, so it should be a git repo already. Dec 16 18:41:19 in a recipe S = "${WORKDIR}" is pointing where ? Dec 16 18:41:23 ndec: I was not complaining. Dec 16 18:41:33 ndec: I think you somewhat misremember the complain... ;-) Dec 16 18:42:03 ndec: I was complaining *why* Yocto does not support embedded git repositories if someone (rightfully) stores the yocto project with custom layers under git. Dec 16 18:42:39 ndec: well, for me, the linux stuff is not a git repository. Dec 16 18:59:58 how can I enforce the kernel rebuild without deleting the fetched folder? Dec 16 19:00:22 maybe bitbake -c cleannstate Dec 16 19:00:31 *cleanstate Dec 16 19:02:22 you mean cleansstate? Dec 16 19:02:31 I will make a backup first. Dec 16 19:02:50 yes, cleansstate Dec 16 19:03:06 cleansstate keeps donwnload in downloads folder Dec 16 19:03:13 if you want to remove that as well use cleanall Dec 16 19:03:24 ah I see _without_ now Dec 16 19:03:31 no, I would like to keep the work folder. Dec 16 19:03:34 not just the download Dec 16 19:03:37 cleansstate is right Dec 16 19:03:41 as I have local modifications. Dec 16 19:03:48 ah work folder too? Dec 16 19:03:53 yes Dec 16 19:04:01 -c compile -f Dec 16 19:04:38 virtual/kernel? Dec 16 19:04:40 ^ Dec 16 19:04:49 ah, that was it, thanks. Dec 16 19:04:58 JaMa: good that you walked in before me running cleansstate. :) Dec 16 19:05:52 hmm, the output does not show the compilation warnings by default. Dec 16 19:05:58 is it possible to get them to the stdout? Dec 16 19:06:08 otherwise, warnings can easily sneak in. Dec 16 19:12:56 well I also didn't know that by "fetched folder" you mean workdir :) so making backup is always good thing Dec 16 20:12:54 ndec: are you sure denzil also fetched the linux kernel from git? Dec 16 20:13:48 hmm. i am sure dylan and above do... Dec 16 20:14:05 find ./tmp/work/bar-foo-linux-gnueabi/linux-foo/3.2.1-r3/ -name .git Dec 16 20:14:16 because definitely, this does not return anything, really. Dec 16 20:15:12 ndec: ^ Dec 16 20:15:46 i need a few mins. not with my pc right now Dec 16 20:25:04 <__ccube> hi I am gettin many | ./config.status: line 703: /home/le/build/poky/build/tmp-eglibc/sysroots/x86_64-linux/bin/sed: No such file or directory errors since today. Dec 16 20:26:02 trying to create a new recipe to compile the fcgi library. I am getting the following error : (in configure script) checking whether the C compiler works... configure: error: cannot run C compiled programs if you meant to cross compile, use `--host`. what that means ? and where to add the --host ? Dec 16 20:31:51 lpapp: yes, i definitely get the .git with dylan. Dec 16 20:32:02 ndec: denzil? Dec 16 20:32:08 ^^ Dec 16 20:32:47 something changed on master recently with the git fetcher Dec 16 20:33:21 if your git recipe relies on a tag for checkout it will most likely fail Dec 16 20:33:41 weebet: for configure Dec 16 20:42:43 lpapp: looking at bitbake, the 'git checkout' feature was added in 1.16 version of bitbake which went in danny. so i am afraid denzil does have that. Dec 16 20:42:58 right... Dec 16 20:43:08 unfortunate, but thanks... Dec 16 20:43:33 we use dylan though, but with forked linux kernel package... Dec 16 20:43:39 from denzil Dec 16 20:43:50 is it possible to easily to get the recipe updated to the checkout thingie? Dec 16 20:45:41 lpapp: that's a bitbake fetcher feature, so if your recipe use git:// in SRC_URI, that should be done automatically Dec 16 22:23:12 Hi Dec 16 22:23:45 I would like to ask about conditionally stripping an entry in ${PROVIDES} Dec 16 22:24:15 what I am trying to do here is to remove virtual/kernel from ${PROVIDES} depending on the name of package I will be building Dec 16 22:24:18 I tried this Dec 16 22:24:23 (in my custom linux.inc) Dec 16 22:24:48 PROVIDES_remove = "${@'foo' if PN == 'bar' else ''}" Dec 16 22:24:56 assuming a recent poky/yocto Dec 16 22:25:00 kergoth: 1.5 Dec 16 22:25:03 kergoth: thanks :) Dec 16 22:25:20 kergoth: I didn't even finish putting my idea together and here is a solution already, really, thanks Dec 16 22:25:36 but that sounds questionable, i'd take a step back and make sure that's the right approach first Dec 16 22:25:39 np Dec 16 22:25:58 kergoth: I have a package which produces and SD card image Dec 16 22:26:09 it depends on two different kernel images, which both provide virtual/kernel Dec 16 22:26:13 so I want to remove it from one of those Dec 16 22:26:47 preferred_provider doesn't do it for you? Dec 16 22:27:24 mr_science: my package depends on both linux-foo and linux-bar , both of them have virtual/kernel in PROVIDES, since that comes from kernel.bbclass Dec 16 22:27:47 mr_science: I would like to remove the virtual/kernel from PROVIDES based exactly on PREFERRED_PROVIDER_virtual/kernel Dec 16 22:27:50 you do realize that the two are likely to step on one another and break the build elsewhere, right? they'll both write to STAGING_KERNEL_DIR in teh sysroot, etc Dec 16 22:28:00 unless you override a number of things in one of them Dec 16 22:28:20 right, so your conf might have PREFERRED_PROVIDER_virtual/kernel = "package_foo" Dec 16 22:29:12 mr_science: no, he wants both to build in a single build Dec 16 22:29:20 which bitbake will be unhappy about if both are providing hte same thing Dec 16 22:29:32 but removing the provide isn't going to change the fact that the two really do both provide some of the same things :) Dec 16 22:29:41 bitbake is unhappy for good reason Dec 16 22:30:24 presumably you could override do_install in one of them as well as removing the provide, however Dec 16 22:31:21 kergoth: that's my plan Dec 16 22:31:25 yeah, i have classic build that does both a "nand_setup" image which also builds a rescue_image and uses it as the install payload Dec 16 22:31:28 kergoth: thanks for the help, I will try and see Dec 16 22:31:47 but they use the same kernel so not quite the same thing... Dec 16 22:32:12 Marex_: np Dec 16 22:33:15 Marex_: i could probably help more if i understood your requirements... Dec 16 22:35:45 mr_science: I will break my build soon, so I will beg you soon :) Dec 16 22:36:06 i'd have more time in the evening Dec 16 22:36:20 trying to debug my latest build right now... Dec 16 22:36:40 mr_science: I am already full of coffee Dec 16 22:36:43 yep, xmas are coming Dec 16 22:40:47 kergoth: is this a correct syntax ? PROVIDES="${@'virtual/kernel' if ${PREFERRED_PROVIDER_virtual/kernel} != ${PN} else '' }" ? Dec 16 22:40:54 please ? Dec 16 22:42:25 nope Dec 16 22:42:32 :-( Dec 16 22:42:35 you're using values without quoting Dec 16 22:42:47 it'll expand to someting like 'virtual/kernel' if foo != bar else '' Dec 16 22:42:54 so it'll tread foo and bar as identifiers, not python strings Dec 16 22:43:00 add quotes around your ${} at a minimum Dec 16 22:43:02 PROVIDES="${@'virtual/kernel' if '${PREFERRED_PROVIDER_virtual/kernel}' != '${PN}' else '' }" like this ? Dec 16 22:43:45 yes, but the logic sounds backwards Dec 16 22:43:57 provide a kernel if you aren't going to prefer this kernel? Dec 16 22:44:08 * kergoth shrugs Dec 16 22:44:18 regardless, yes, syntactically that looks reasonable Dec 16 22:44:22 errr Dec 16 22:44:28 PROVIDES_remove="${@'virtual/kernel' if '${PREFERRED_PROVIDER_virtual/kernel}' != '${PN}' else '' }" like this ? Dec 16 22:44:41 should be better I suppose Dec 16 22:44:45 indeed, yes Dec 16 22:44:59 now let me step on my toes :) Dec 16 22:45:08 thank you guys Dec 16 22:45:14 np Dec 16 22:46:43 should i not use PROVIDES -= instead ? Dec 16 22:46:58 there's no such thing as -= Dec 16 22:47:01 so no Dec 16 23:01:37 kergoth: are you sure about the conditional in there ? Dec 16 23:02:03 PROVIDES_remove="${@'virtual/kernel' if '${PREFERRED_PROVIDER_virtual/kernel}' != '${PN}' else 'virtual/kernel' }" does never remove the 'virtual/kernel' Dec 16 23:05:57 aaah Dec 16 23:06:02 PROVIDES_remove := Dec 16 23:06:13 is it just me or do you have virtual/kernel in both branches? Dec 16 23:06:28 JaMa: I want to check if it's ever removed or not, so that was intended Dec 16 23:06:37 ah ok Dec 16 23:10:47 hm ... noes Dec 16 23:10:51 this := doesn't work either Dec 16 23:10:58 virtual/kernel is never removed from PROVIDES Dec 16 23:19:22 Marex_: seems like you really want just one virtual/kernel provider Dec 16 23:19:47 maybe have your other kernel recipe provide something else instead Dec 16 23:30:52 mr_science: indeed Dec 16 23:30:57 mr_science: why can I not use the _remove ? Dec 16 23:49:15 no idea, never tried that one... Dec 16 23:50:10 mr_science: I will now go drop into the bed Dec 16 23:50:14 mr_science: thanks for the help! Dec 16 23:50:48 not that it was all that helpful, but okay... **** ENDING LOGGING AT Tue Dec 17 02:59:59 2013