**** BEGIN LOGGING AT Mon Aug 12 02:59:58 2013 Aug 12 07:33:45 good morning Aug 12 07:59:43 morning all Aug 12 07:59:51 morning bluelightning Aug 12 08:27:48 morning all Aug 12 08:46:17 morning all. can anyone help me how to create ext2.gz.u-boot image? i already enable IMAGE_FSTYPE = "ext2.gz ext2.gz.u-boot" but image does not create Aug 12 08:46:59 uvan: u-boot or kernel binary? Aug 12 08:47:22 uvan: if kernel, what is the problem with uImage? Aug 12 08:47:56 i want to create a "ramdisk" with will work with u-boot Aug 12 08:48:43 ah, I see. Aug 12 08:49:00 uvan: image built though? Aug 12 08:49:04 and also want to create uImage too. right now i just only can create Image only. i think i miss something to enable u-boot mkimage Aug 12 08:50:42 uvan: have you checked this? http://comments.gmane.org/gmane.linux.embedded.yocto.general/2640 Aug 12 08:52:02 lpapp: yes, not yet. let me try Aug 12 08:57:40 thanks lpapp: it's building. wait for result Aug 12 09:01:49 uvan: hope it helps. Aug 12 09:03:48 same with that topic. i got ERROR: cannot map 'allarch' to a linux kernel architecture. Aug 12 09:27:30 hi guys, I set my TCLIBC=uclibc and during build eglibc-initial gets compiled. Why is that? Can I stop it? Aug 12 09:28:25 Krz_: are you using an external toolchain or not? Aug 12 09:29:29 Krz_: I don't know but you can use the '-g' option of bitbake and browse the dependencies Aug 12 09:30:09 now I'm using linux x64 as host, and setting SDKMACHINE to mingw32 (have my own machine configuration file) Aug 12 09:31:09 Krz_: I only had such experience when the toolchain was set up wrong, but perhaps there are other scenarios, too. Aug 12 09:31:30 Krz_: check that TCLIBC is actually being set to that value using bitbake -e | grep ^TCLIBC= Aug 12 09:33:24 TCLIBC gets set properly. package-depends.dot shows: "nativesdk-eglibc-initial" -> "automake-native" "nativesdk-eglibc-initial" -> "libtool-native" and few others Aug 12 09:33:45 so proably no way to stop eglibc-initial getting compiled :/ Aug 12 09:37:14 shoragan: ping? Aug 12 09:44:40 Krz_: right, that's the key thing - it's nativesdk-eglibc-initial not eglibc-initial Aug 12 09:46:32 Krz_: I could be wrong but I don't know that we currently support building SDKs for other libcs - and this is demonstrated by the fact the TCLIBC="uclibc" configuration explicitly selects eglibc as the provider for the nativesdk variants Aug 12 09:47:10 not to say it can't be done, just that it's not supported out of the box Aug 12 10:08:42 Krz_: Is this related to the question on the mailing list about building mingw32 toolchains?> Aug 12 10:11:47 yes Aug 12 10:12:04 I just need a xcompiler toolchain under windows Aug 12 10:12:15 so trying everything Aug 12 10:13:26 Krz_: The key thing to realise is the way we build our normal cross compilers is to link them to their own libc. On windows you do not want to do that so you don't want any nativesdk-libc Aug 12 10:13:42 Krz_: you probably need to add something to ASSUME_PROVIDED along those lines Aug 12 10:22:01 hi lpapp: add inherit image_types_uboot to images.bbclass can make ext2.gz.u-boot rule work Aug 12 10:22:15 uvan: \o/ Aug 12 10:22:39 but unfortunately mkimage not support arch is ARM64. so i need more work Aug 12 10:22:41 RP: I don't really get it. I still to link my xcompiler against some libc under windows Aug 12 10:23:27 uvan: hmm? Have you passed the right parameters to mimage? Aug 12 10:23:34 RP: actually I have to link against what TCLIBC specifies Aug 12 10:23:35 uvan: I think the correct method is to set IMAGE_CLASSES = "image_types_uboot" FYI Aug 12 10:23:37 Krz_: windows binaries don't have a libc, they have some kind of windows system dlls ? Aug 12 10:24:03 Hey, I have got some issu with QtE. I bitbake meta-toolchain-qte and now I want to cross_compile my Qt projects. I found tmp/sysroots/i686-linux/usr/bin/qmake2, but when i try to execute it I have got the "QMAKESPEC has not been set, so configuration cannot be deduced" issue. Aug 12 10:24:03 Can someone tell me what I have to do? Aug 12 10:24:36 thanks blueligtning. i will do. Aug 12 10:25:14 lpapp: mkimage only support valid names are: alpha, arm, x86, ia64, m68k, microblaze, mips, mips64, nios2, powerpc, ppc, s390, sh, sparc, sparc64, blackfin, avr32 Aug 12 10:25:21 but i need arm64 Aug 12 10:25:38 not sure how that is Yocto related. Aug 12 10:25:41 maybe i missed confiure something Aug 12 10:25:51 yes i known Aug 12 10:26:09 arm64 is very new, so you'll often be finding the limits of where the support is currently Aug 12 10:26:09 I have never used arm64. :) Aug 12 10:26:24 uvan: you may need to build for arm32, then. Aug 12 10:26:35 and when the u-boot tools get more support, you can switch. Aug 12 10:26:45 uvan: which u-boot version have you built btw? Aug 12 10:26:58 my jobs is support arm64 for Yocto Aug 12 10:27:09 but i'n new to yocto Aug 12 10:27:26 uvan: looks like you've found something to fix :) Aug 12 10:27:39 uvan: but what can you do if u-boot does not support it? Aug 12 10:27:41 Hi all, hi otavio. I'm getting this build error using meta-fsl-* from master-next: http://pastebin.com/MdAa7Rj4 Aug 12 10:27:45 That is not Yocto material if you use the latest u-boot. Aug 12 10:27:58 that is why I asked if you had been using that. Aug 12 10:28:32 actually we already supported. but not for yocto yet Aug 12 10:29:14 uvan: you are a u-boot dev? Aug 12 10:29:23 uvan: well, I have the latest u-boot patches on the mailing list. Aug 12 10:29:26 you can grab them. Aug 12 10:29:29 2013.07 Aug 12 10:30:06 yes, we already ported uboot for arm64. but we not use yocto before Aug 12 10:30:11 thanks lpapp Aug 12 10:30:18 uvan: grab my changes, and be done. :) Aug 12 10:30:37 you may need to update the checksum... I could not update the change to be honest due to other blockers that no one cares about atm. Aug 12 10:30:55 i see. thanks Aug 12 10:42:14 TuTizz: rather than executing the native qmake you should install the SDK and use that Aug 12 10:42:33 TuTizz: i.e. install the SDK that was created when you built meta-toolchain-qte Aug 12 10:44:03 bluelightning, tmp/deploy/sdk/poky-eglibc-i686-arm-toolchain-qte-1.3.2.sh ? Aug 12 10:44:12 TuTizz: yes Aug 12 10:44:44 bluelightning, ok thanks you Aug 12 10:44:49 uvan: g2g, good luck Aug 12 10:45:17 lpapp: thanks Aug 12 12:48:13 where do I find recipes for all native tools? Aug 12 13:08:10 Krz_: in the same place as all other recipes Aug 12 13:08:32 Krz_: note that some native tools are produced via BBCLASSEXTEND = "native" in target recipes Aug 12 13:08:46 so e.g libtool-native uses libtool.bb recipe? Aug 12 13:09:30 Krz_: no, libtool-native is its own recipe Aug 12 13:20:16 BBCLASSEXTEND means I have one recipe to handle native host and sdk host versions? Aug 12 13:20:47 Krz_: depends on the value set for BBCLASSEXTEND Aug 12 13:21:30 Krz_: BBCLASSEXTEND = "native nativesdk" would handle target (default), native (build host) and nativesdk (SDK) Aug 12 13:22:01 Krz_: or you could just have BBCLASSEXTEND = "native" or BBCLASSEXTEND = "nativesdk" Aug 12 13:22:26 but then all of the steps in recipe are shared, right? Aug 12 13:22:41 if I want totally different do_configure Aug 12 13:22:49 then I need two recipes? Aug 12 13:23:34 Krz_: you can do a do_configure_class-native () Aug 12 13:23:52 ok, that sounds Aug 12 13:24:13 i presume do_configure_class-nativesdk exists as well ? Aug 12 13:24:58 Krz_: yes, I believe so Aug 12 13:26:48 I have to provide bunch of bbappends for all nativesdk tools for mingw, since Yocto tries to build eglibc-initial-nativesdk for them, and they don't need it (and eglibc does not compile for mingw) Aug 12 13:47:12 Krz_: can't you just add virtual/nativesdk-libc to ASSUME_PROVIDED? Aug 12 14:36:59 RP, welcome back Aug 12 14:37:36 Crofton|work: thanks Aug 12 14:38:25 Krz_: I had a look at mingw32, its been a while. Its runtime libs look like an equivalent to nativesdk-libc so you probably need a recipe which PROVIDES that Aug 12 14:39:18 there is a guy: Francois, he is in the middle of the work here: Aug 12 14:39:20 git://github.com/fgretief/meta-mingw Aug 12 14:39:45 so far the layer produces gcc-crosssdk Aug 12 14:39:55 for mingw Aug 12 14:41:25 and next step is exacty what you are talking about Aug 12 14:48:13 recipe which provides nativesdk is already done Aug 12 14:48:42 the trick is to tell all nativesdk packages to use it and where to find it Aug 12 14:49:16 recipe which provides nativesdk-libc is already done* Aug 12 14:51:48 sounds like you're just missing some PROVIDES or associated PREFERRED_PROVIDER_ variables. Aug 12 14:57:42 I'm having all sorts of issues getting poky working. I've tried with ubuntu 12.04.2 lts and 13.04, same results. getting lots of compile failures. Tried all the docs, not really finding anything useful except I may be able to use external compiler, but which one is the best to use? Aug 12 14:58:56 not sure why poky doesn't work "clean out of box". Ready to give up. Aug 12 14:59:07 cfo215: what kind of compile failures? Aug 12 14:59:46 p[astebin the messages Aug 12 14:59:55 rp: i'll grab an example. Aug 12 14:59:56 cfo215: also which version of poky are we talking about? Aug 12 15:00:06 git clone of current master Aug 12 15:00:58 ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;bareclone=1;branch=standard/base,meta;name=machine,meta'. Unable to fetch URL from any source. Aug 12 15:02:01 I had 3 warnings and 29 failures trying to bitibake core-mage-sato for qemuarm. Aug 12 15:02:05 cfo215: ok, that isn't a compile failure, its a fetching failure Aug 12 15:02:26 yeah, sorry bout that, let me grab a compile error. Aug 12 15:02:31 firewall issues? Aug 12 15:02:38 cfo215: its trying to clone a git repository and failing and also can't get to the mirrors for some reason Aug 12 15:03:00 ERROR: Logfile of failure stored in: /home/epic/poky/build/tmp/work/armv5te-poky-linux-gnueabi/gstreamer/0.10.36-r2/temp/log.do_unpack.6515 Aug 12 15:04:21 cfo215: that still isn't a compile failure, it is unable to unpack something Aug 12 15:04:27 cfo215: I'd start with fixing the download issues Aug 12 15:04:48 cfo215: can you wget files from the commandline? Aug 12 15:05:03 yes Aug 12 15:05:07 x86_64-linux-libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib -I.. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/include -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/generic -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/include -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/includ Aug 12 15:05:10 e -O2 -pipe -c /home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib/ErrorCountEventHandler.cxx -o ErrorCountEventHandler.o >/dev/null 2>&1 Aug 12 15:05:12 ../x86_64-linux-libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib -I.. -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/include -I/home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/generic -isystem/home/epic/poky/build/tmp/sysroots/x86_64-linux/usr/include -isystem/home/epic/poky/build/tmp/sysroots/x8 Aug 12 15:05:14 6_64-linux/usr/include -O2 -pipe -c -o EventGenerator.lo /home/epic/poky/build/tmp/work/x86_64-linux/opensp-native/1.5.2-r1/OpenSP-1.5.2/lib/EventGenerator.cxx Aug 12 15:05:17 The bug is not reproducible, so it is likely a hardware or OS problem. Aug 12 15:05:19 make[3]: *** [EntityApp.lo] Error 1 Aug 12 15:05:23 cfo215: use pastebin for something that isn't a single line Aug 12 15:05:34 where would you like me to paste bin to? Aug 12 15:06:05 cfo215: building a linux OS from scratch does stress machines a bit so if you have broken hardware, this will likely expose it Aug 12 15:06:08 I've been strugling with yocto/poky for weeks now. Aug 12 15:06:42 cfo215: pastebin.com Aug 12 15:06:47 my machine is i7 quad core with 12gb ram 1TB drive. Aug 12 15:07:27 bluelightning: thank you. Aug 12 15:10:07 RP: I have no issues with wget: Aug 12 15:10:10 epic@epic-dev02:/tmp$ wget http://bitmath.org/code/mtdev/mtdev-1.1.2.tar.bz2 Aug 12 15:10:12 --2013-08-12 11:09:32-- http://bitmath.org/code/mtdev/mtdev-1.1.2.tar.bz2 Aug 12 15:10:15 Resolving bitmath.org (bitmath.org)... 46.30.211.48 Aug 12 15:10:19 Connecting to bitmath.org (bitmath.org)|46.30.211.48|:80... connected. Aug 12 15:10:21 HTTP request sent, awaiting response... 200 OK Aug 12 15:10:24 Length: 266202 (260K) [application/x-tar] Aug 12 15:10:26 Saving to: ‘mtdev-1.1.2.tar.bz2’ Aug 12 15:10:34 100%[======================================>] 266,202 217KB/s in 1.2s Aug 12 15:10:38 2013-08-12 11:09:34 (217 KB/s) - ‘mtdev-1.1.2.tar.bz2’ saved [266202/266202] Aug 12 15:10:54 RP: what OS do you use? Aug 12 15:11:11 i'd try git cloning the linux-yocto-3.8 kernel that failed to fetch via bitbake, manually Aug 12 15:12:08 I thought the whole purpose of using poky was so I wouldn't have to do individual fetching and building of stuff. I understand you're trying to help me. Aug 12 15:12:27 i'm saying you should clone so we know that cloning works Aug 12 15:12:30 as a data point in trying to debug Aug 12 15:12:39 this is how debugging works, you eliminate possible sources of failure until one remains Aug 12 15:12:59 will do. Clone into the poky directory or somewhere else? Aug 12 15:13:19 doesn't matter, the point is whether teh clone succeeds, not to put it somewhere bitbake will get it Aug 12 15:13:29 ok w1 Aug 12 15:16:56 cfo215: As well as trying that, you could pastebin the output of one of your bitbake runs showing the error and warning messages you're seeing. We're trying to figure out what in your setup isn't working... Aug 12 15:17:26 cfo215: only seeing some of the messages makes things tricky for us as we don't have the complete picture Aug 12 15:18:00 will do. will the cooker log work or do you need something else? Aug 12 15:20:50 RP:kergoth: my gut tells me the order of downloads is out of wack somehow. bitbake isn't waiting for things to finish before trying other things. i.e. dependancies aren't there for the compiler to work properly. Aug 12 15:21:37 cfo215: a look at the cooker log would be a good start Aug 12 15:22:03 cfo215: the system is setup to do things in parallel so that may or may not be true Aug 12 15:22:19 kergoth:RP: git clone of linux-yocto-3.8 kernel running just fine right now. Aug 12 15:22:20 cfo215: I would have expected someone else to have seen it though Aug 12 15:22:33 I'll pastebin the latest log Aug 12 15:24:55 panda84kde: did you fix the build failure? Aug 12 15:30:21 RP: "yocto-compile-issues-20130812-01" on pastebin that was my last try prior to the one that is currently running. Aug 12 15:30:32 RP: it also had compile failures. Aug 12 15:31:18 cfo215: do you have the pastebin url? Aug 12 15:31:37 http://pastebin.com/qDsR4UpW Aug 12 15:33:30 kergoth: git clone worked without issue. I use exact line shown in the log file. Aug 12 15:33:53 cfo215: so bintuils-native and gcc-cross-initial failed. If you try building them again with "bitbake binutils-native gcc-cross-initial" do they get any further? Aug 12 15:34:10 cfo215: also, why earlier did you wonder about hardware issues? You've seen something build that had previously failed? Aug 12 15:34:51 worrried that I'm outrunning bitbake with my hardware somehow. Aug 12 15:35:51 RP: trying that now... Aug 12 15:36:20 otavio: no :( Aug 12 15:36:46 RP: That didn't work either... "ERROR: Task 19 (/home/epic/poky/meta/recipes-devtools/gcc/gcc-cross-initial_4.8.bb, do_compile) failed with exit code '1'" Aug 12 15:36:56 cfo215: that's extremely unlikely, the build system gets run regularly on such machines Aug 12 15:37:09 I'll pastebin the do_compile log Aug 12 15:37:53 bluelightinging: I wouldn't be here if I wasn't having trouble... again. I know you're trying to help. Aug 12 15:39:47 all he said was that your assumption about outrunning bitbake was extremely unlikely, not that you weren't having a problem Aug 12 15:39:54 cfo215: of course... we'll do whatever we can to assist Aug 12 15:40:47 bluelightning: thank you. I really,l really (no, I didn't stutter) do appreciate any help I can get. Aug 12 15:41:01 panda84kde: I will have lunch and then I check it with you. Ok? brb Aug 12 15:41:20 pastebin of ERRO: Task 19... http://pastebin.com/JJ6SJYzA Aug 12 15:42:25 otavio: sure Aug 12 15:42:28 cfo215: ok, next can you try "bitbake gcc-cross-initial -c cleansstate; bitbake gcc-cross-initial" Aug 12 15:42:34 good lunch otavio Aug 12 15:43:24 cfo215: silly question, but have you checked that your machine isn't having cooling issues? Aug 12 15:44:30 cfo215: if this rebuilds ok, it does sound like the error mentioned there might be a clue "The bug is not reproducible, so it is likely a hardware or OS problem." :/ Aug 12 15:44:30 bluelightning: no, haven't checked that and wouldn't know where to begin to find out. Aug 12 15:44:50 RP: What OS do you use? Aug 12 15:45:07 cfo215: you could try two things, one would be to run memtest on it, check there isn't bad memory, you could also try turning down the parallism (PARALLEL_MAKE and BB_NUMBER_THREADS) Aug 12 15:45:14 cfo215: Ubuntu of various versions Aug 12 15:45:55 cfo215: I know of several people using it regularly which is why I don't think its the problem Aug 12 15:46:04 I can try that. my setting are "8" as per documents'.... quad core x 2. Aug 12 15:46:19 cfo215: equally I know of people using this on 24 core systems so I don't think this is a parallelism issue Aug 12 15:46:35 cfo215: I do suspect your hardware unfortunately :( Aug 12 15:47:08 That wouldn't surprise me none. It was a hand me down from the IT department... I'm a contractor.... Aug 12 15:48:19 RP: "The bug is not reproducible, so it is likely a hardware or OS problem. Aug 12 15:48:21 | make[1]: *** [insn-recog.o] Error 1 Aug 12 15:48:23 | rm gcc.pod" Aug 12 15:48:44 RP: I'm going shopping.... time to get a new computer.... Aug 12 15:49:11 cfo215: it failed in a different file? That has all the signs of hardware issues :/ Aug 12 15:49:13 RP: Any recommendations? I've not purchased a computer in years... Aug 12 15:49:58 cfo215: the spec you mentioned (i7 with 12GB ram and 1TB disk) sounded like the right ballpark Aug 12 15:50:42 I'll look for something in that neighborhood. Thanks for all your help. I'm going now to give back this POS computer. Aug 12 15:51:06 I'll come back later and let you know how it went with the new compter. Aug 12 15:51:12 good luck :) Aug 12 15:51:19 thanks Aug 12 16:59:45 panda84kde: I am around :) Aug 12 17:00:07 zedd_, I'm thinking line 10 is a bad idea here: https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-yocto_3.8.bbappend#L10 Aug 12 17:03:40 Crofton|work, saw your email this morning. is it causing you direct pain ? Aug 12 17:06:00 as opposed to indirect? Aug 12 17:06:29 * mr_science is in an extra-sarcastic mood today Aug 12 17:06:42 so i'll try to abstain... Aug 12 17:06:58 hi. Try bitbaking mesa-demos and see if it builds for you Aug 12 17:07:07 * hi otavio Aug 12 17:08:18 well, I had to rename a scc file to get my bbappend to build Aug 12 17:08:36 then I got wondering how mulitple bbappends across several bsps's will work Aug 12 17:11:07 it seems like the bbappends to linux-yocto will stack across all bsps? Aug 12 17:11:26 can you forward me the error/issue you saw, I can suggest a tweak if I have a better picture. Aug 12 17:12:53 basically it looked for the file my-machine-standard.scc Aug 12 17:12:58 which did not exist Aug 12 17:13:24 yup. and found that one ? Aug 12 17:14:05 well, it found it after I renamed one of my .scc files Aug 12 17:15:40 heh. let me try and get it straight in my head. it didn't find my-machine-standard.scc, but found another one of your .scc files that you didn't want it to find, and when you renamed that one, it found the xilinx one ? Aug 12 17:16:07 no Aug 12 17:16:35 I add my layer that bbappends to linux-yocto and has a new machine name Aug 12 17:16:51 so it fails, because I do not have a file new-machine-standard.scc Aug 12 17:17:33 right. it either fails or tries to generate you one. Aug 12 17:17:48 it tries to make one? Aug 12 17:18:03 but this is anme from a xilinx bbappend? Aug 12 17:18:04 what failure did you get ? I can diagnose why it failed if there was a message. or did you just get something built you didn't want ? Aug 12 17:18:22 https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-yocto_3.8.bbappend#L10 Aug 12 17:18:45 OH. Aug 12 17:19:17 right, the bbappend shouldn't demand that. now I understand. it should be something that you can override in your layers. Aug 12 17:20:42 yeah Aug 12 17:21:00 and I assume mulitple bbppends will stack? Aug 12 17:21:05 yep. Aug 12 17:21:18 Crofton|work: bsp layers should always use the machine overrides for both their variables and their files in filespath Aug 12 17:21:31 so they don't break others, and so they have no impact when their machine isnt' used Aug 12 17:21:40 th eonly exception is general bugfixes, but they don't belong in bsp layer anyway Aug 12 17:22:14 yeah Aug 12 17:22:22 imo the same is true of distro layers too, anything specific to taht distro should be using the distro override, again the only exception being general bugfixes Aug 12 17:22:37 it would be nice to have a script that we could run against a layer to check if it's following that Aug 12 17:22:50 Hmm, yeah, that's a good idea Aug 12 17:22:50 with the variable history stuff it probably wouldn't be too hard Aug 12 17:23:46 could just dump global and per-recipe metadata before and after inclusion of the layer, without changing hte config, and list what changes occurred solely due to layer inclusion Aug 12 17:23:50 * kergoth shrugs Aug 12 17:29:20 gah, I need these patches in the xilnx bbappend to apply for all zynq machines Aug 12 17:42:35 Crofton|work: time to either add/use an override for that class of machines / soc, or define it using all the machien overrides :) Aug 12 17:43:32 the headache is I add my new amchine in another bbappend, btu I still need the zynq specific patches Aug 12 17:44:02 I may go use their -dev recipe instead of linux-yocto Aug 12 17:44:17 there still appear to be ascaling issues Aug 12 17:44:55 presumably you could just include both zyng and your machien in MACHINEOVERRIDES, fi both always apply Aug 12 17:45:12 thats what i do for th emel distro, we apply both poky and mel overrides via DISTROOVERRIDES, since we're poky based Aug 12 17:45:27 /e/me shrugs Aug 12 17:46:02 s/^..// Aug 12 17:46:19 have a napkin... Aug 12 17:55:43 Crofton|work: I'm currently trying to do something similar and need the linux-yocto-dev reciepe for the beagleboard. Where do I enable this? Aug 12 17:56:31 I thought it would be meta-yocto-bsp/conf/machine/beagleboard.conf but that didn't help. Aug 12 18:11:57 can anyone tell me if its a bug or what Aug 12 18:12:14 let say I have two versions of libfoo: libfoo_1.0.bb and libfoo_git.bb Aug 12 18:12:26 some other recipes RDEPENDS on it Aug 12 18:13:00 I built libfoo_1.0.bb first and then libfoo_git.bb Aug 12 18:13:04 thats fine Aug 12 18:14:13 but when I build any package that RDEPENDS on this libfoo, altough my recipe says that "please, give priority to libfoo_git", the package adds a dependency version on libfoo >= 1.0 Aug 12 18:14:28 but if I do a bitbake -s, it shows the git version Aug 12 18:15:06 actually everything looks correct, just this run time dependency for other packages is not correct Aug 12 18:54:43 ftonello: shouldn't it prefer git recipes over versioned ones? Aug 12 18:55:34 ftonello: we don't support two different versions like that Aug 12 18:55:48 ftonello: see clutter for how to namespace different ABIs Aug 12 18:55:53 (as an example) Aug 12 18:57:29 is it really an ABI difference? or just an "i need the latest in git instead of 1.0" thing? Aug 12 18:58:59 the only thing i can think of is have libfoo_git RPROVIDE some (different) name to DEPEND on Aug 12 18:59:28 might not be "proper" though... Aug 12 19:01:35 the two things have the same provides namespace so only one can be built. If you need to build both, you need different PN namespaces Aug 12 19:02:20 RP, mr_science: Yes. The think is that I have a env variable that selects that for me. I change the priority based on that Aug 12 19:02:33 so what I did, I told bitbake to select the git recipe for the build Aug 12 19:02:49 but when it generates the package information, is selecting the other version of the package Aug 12 19:03:09 the other package information should have been cleaned out when the other recipe was built :/ Aug 12 19:03:41 RP: yes.. where this information is stored? Because I coudn't find it.. Aug 12 19:03:44 it seems to be a bug Aug 12 19:03:46 ftonello: you already changed the priorities, right? Aug 12 19:03:52 mr_science: yes.. Aug 12 19:04:12 I do this: Aug 12 19:04:15 DEFAULT_PREFERENCE = "${@use_git_or_not()}" Aug 12 19:04:26 and this function checks for that variable and return -1 or 1, Aug 12 19:04:55 it works well.. just this is not working Aug 12 19:13:56 I oppened a bug Aug 12 19:13:58 let see Aug 12 19:15:28 5008 Aug 12 19:17:17 and the winner of #5000 is belen! Aug 12 20:06:47 kergoth, is this a job for SOC_FAMILY? Aug 12 20:10:11 Crofton|work: MACHINEOVERRIDES Aug 12 20:11:49 you see the problem, there are files in a linux-yocto.bbppend that apply for all machines in a class Aug 12 20:12:01 and some that apply for specific machines Aug 12 20:12:35 Crofton|work: SOC_FAMILY is MACHINEOVERRIDES behind the scenes Aug 12 20:12:38 and is there a good example anywhere Aug 12 20:12:47 yeah, but the wording makes sense :) Aug 12 20:13:11 * Crofton|work is looking at soc-family.inc :) Aug 12 21:02:41 RP, when you have a minute, I would be interested in feedback on the patch I sent recentlyish (July 26) for NO32LIBS. Basically, it makes the attempt to build a 32-bit pseudo more definite if NO32LIBS gets set to 0, on the grounds that if you are explicitly setting that, and it won't work, you probably want a failure message rather than a corrupted build. Aug 12 21:24:09 seebs: even with NO32LIBS I can still see file attributes (permissions, owners) randomly changing when comparing builds on different hosts with buildhistory, do you have another idea what could be the cause? Aug 12 21:24:47 The most obvious thing is: Right now, NO32LIBS="0" doesn't actually cause 32-bit pseudo to get built. Aug 12 21:24:48 32-bit/64-bit split(s), and static binaries are the only cases where I know it can happen.. Aug 12 21:24:48 seebs: still in the distro with 32bit external toolchain on 64bit builders Aug 12 21:25:01 unless of course something gets added/removed/modified outside of pseudo control Aug 12 21:25:11 It causes 32-bit pseudo to consider getting built if the host system has enough stuff that the build system is pretty sure it can do it, otherwise nothing happens and it's silent. Aug 12 21:25:30 Which is why I sent a patch to try to force it to do the rebuild in that case. Aug 12 21:25:56 ok I'll backport that patch to dylan and test it in our scenario Aug 12 21:26:05 You should be able to check pretty easily. Aug 12 21:26:20 Check your sysroot's pseudo/lib* directories, see how many libpseudo.so you have. Aug 12 21:26:33 If you only have a lib64/libpseudo.so, then it's not building the 32-bit one. Aug 12 21:29:54 I've checked 2 builders and both have both 32+64 libpseudo built Aug 12 21:52:11 Huh, that's odd, then. Aug 12 21:52:26 Got any failures to load libpseudo.so in there? Anything interesting in the pseudo.log files? **** BEGIN LOGGING AT Mon Aug 12 22:07:04 2013 Aug 12 22:18:21 seebs: unfortunately I don't have simple reproducer I only know about it from buildhistory diffs and sometimes when it hits some file in image where it has fatal behavior for runtime Aug 12 22:18:50 seebs: but I haven't seen anything interested in pseudo.log or preload failures Aug 12 22:18:53 Yeah. We had that for a while, but NO32LIBS fixed it for us, and we haven't seen it since, that we know of. Aug 12 22:19:08 It's possible that there's also packages which are tripping pseudo some other way. Aug 12 22:19:17 Hmm. Any NFS involved? We know there are problems with NFS. Aug 12 22:19:42 sstate mirror and premirror are over NFS Aug 12 22:21:03 tomorrow I'll try to repeat clean builds few times on the same host to see if the problem can be reproduced also on the same host machine Aug 12 22:26:21 I don't think the sstate mirror should matter. The usual failure mode is just that if you remount NFS file systems you don't always get the same device number. Also, pseudo's locking can and will fail if the pseudo directory is NFS-mounted. (Yes, there's a locking syscall that works over NFS, but the locks aren't inherited by child processes.) Aug 12 23:03:33 happy monday everyone! My image is built with GDM, but I don't get the universal access icon any longer (it was there some months ago..). I just need a virtual keyboard to login on a touch screen device Aug 12 23:03:59 my GDM recipe indicates i'm using 2.32.2 Aug 13 00:16:53 b1gtuna: i'll be working on a slim recipe shortly, but i don't think that will help you... Aug 13 00:17:42 pretty sure it only has F1 session select, but if you find it has more access support, yell at me... **** ENDING LOGGING AT Tue Aug 13 02:59:59 2013