**** BEGIN LOGGING AT Fri Oct 04 02:59:59 2013 Oct 04 08:46:13 morning guys! Oct 04 08:46:52 is there a way to have bitbake build a package but not install it in my image? (so I have it available in my repo but it is not pre-installed) ? Oct 04 08:47:09 maybe make the image depend on the package or something like that? Oct 04 08:47:51 hsychla: "bitbake core-image-console anotherpackage" Oct 04 08:49:11 yes, sure. but with that way I will always have to remember which packages I want to build with the image which could be quite a list. I could of course just use a shell script or a bash alias but am looking for something I can commit into our company git Oct 04 08:50:53 hi Oct 04 08:51:56 how to copy the files in image folder to packaegsplit folders? example i have a module called tzdata, i need output in tzdata as well as in individual packaes-split folder tzdata-america Oct 04 08:51:59 any idea? Oct 04 08:52:26 i have given like this FILES_${PN}="${datadir}" Oct 04 08:52:40 FILES_${PN} +="${datadir}" Oct 04 08:52:59 so now total output is copied into tzdata and other folders are emplty Oct 04 08:53:01 empty* Oct 04 08:56:28 how to copy the files in image folder to packaegsplit folders? example i have a module called tzdata, i need output in tzdata as well as in individual packaes-split folder tzdata-america Oct 04 08:56:40 i have given like this FILES_${PN} +="${datadir}" Oct 04 08:56:47 so now total output is copied into tzdata and other folders are emplty !! Oct 04 08:57:57 can i give like this RDEPENDS_tzdata = "tzdata-america" and RPROVIDES_tzdata-americas = "tzdata-americas" ?? Oct 04 08:58:24 all i need is every timezone info should be copied into rootfs! Oct 04 08:58:44 i mean in tzdata module all package split folders ! Oct 04 08:58:52 any idea please Oct 04 09:06:37 hsychla: i think you can do only this as I say it. Maybe you write a buildlist file "echo core-image-console anotherpackage > buildlist" and the do a "bitbake $(cat buildlist" Oct 04 09:08:36 silviof, thanks. Oct 04 09:13:41 morning all Oct 04 09:14:09 morning bluelightning and #oe Oct 04 09:14:42 Sj_: files go into the first package in PACKAGES whose FILES variable matches the file path Oct 04 09:15:36 Sj_: so you'd need to set FILES_tzdata-america (or perhaps FILES_${PN}-america depending on how PACKAGES is specified) Oct 04 09:16:42 hi Oct 04 09:16:54 hsychla: all the image/rootfs stuff is done in do_rootfs() so maybe you can create a fake image with an empty do_rootfs() function, and it would build all packages only... Oct 04 09:17:10 hsychla: to answer your question, add your supplementary package to EXTRA_IMAGEDEPENDS in the image recipe Oct 04 09:18:04 I am trying to build meta-toolchain with OE core, I set a custom SDKPATH and one part of the SDK indeed goes there, but another part still unpacks to usr/local/angstrom-eglibc-x86_64-armv5te/sysroots/x86_64-angstromsdk-linux/ - what am I missing? I want to have it somehwere else but not in /usr/local Oct 04 09:18:59 bluelightning: aah I have search for such thing too long time ago :-P thx :-) Oct 04 09:20:00 ndec, bluelightning, thanks to both of you Oct 04 09:20:51 Jin^eLD: which part are you seeing that's going into the old path? Oct 04 09:21:54 anyone working bb files related to timezones in ubuntu Oct 04 09:22:04 https://pastebin.mozilla.org/3193182 and so on... Oct 04 09:22:28 bluelightning: I can make a full paste if needed Oct 04 09:22:31 it's quite a lot Oct 04 09:24:20 bluelightning: the environment setup script also goes there Oct 04 09:24:34 ok that last bit ought to point to the issue Oct 04 09:24:47 I have to admit I am on a somewhat older revision though... Oct 04 09:25:05 Jin^eLD: what version are you using? Oct 04 09:26:02 openembedded-core with latest commit: Oct 04 09:26:03 commit 6e2b53f47da0e97271fb51b281d24da1e1d549cc Oct 04 09:26:03 Author: Khem Raj Oct 04 09:26:03 Date: Wed Nov 30 19:07:07 2011 -0800 Oct 04 09:27:09 I guess I can not easily upgrade only the meta-toolchain stuff becaue it all will be very much interconnected? Oct 04 09:29:17 ok let me check that version Oct 04 09:29:33 thank you Oct 04 09:30:55 hmm, it still appears to be using SDKPATH for the env setup script in that version as well Oct 04 09:31:48 I am not sure why one part loses the path.. Oct 04 09:32:17 also, SDK_NAME when set in local.conf unpacks to oecore-x86_64-INVALID which is a bit odd Oct 04 09:32:44 er, that is odd yes Oct 04 09:32:54 but at least that part goes to the correct path Oct 04 09:33:31 that means TARGET_ARCH is not set at the time that SDK_NAME is being expanded Oct 04 09:33:38 you're not using := are you? Oct 04 09:34:01 oops :) well I first tried with = and then tried := because I thought someone would overwrite the SDKPATH Oct 04 09:34:07 I'll get rid of the : then Oct 04 09:34:58 question remains where things get overwritten so that one part goes to /usr/local Oct 04 09:42:00 yes, I'm not sure about that Oct 04 09:42:27 := won't prevent anything overwriting a value, that just forces it to be evaluated immediately as opposed to when needed Oct 04 09:42:38 oh I seee Oct 04 09:49:20 good morning Oct 04 09:50:04 mckoan, or afternoon ;) Oct 04 09:50:39 bluelightning: ok, the name is fine now, but one part still lands in /usr/local instead of the specified SDKPATH :P Oct 04 09:52:55 Jin^eLD: not quite sure how that could happen to be honest :/ Oct 04 09:53:18 can you give me some hints on where to look? I am not sure how the meta-toolchain stuff is interconnected... Oct 04 09:53:58 Jin^eLD: well the construction of the SDK is in meta/classes/populate-sdk.bbclass (for the version you are using) Oct 04 09:54:14 Jin^eLD: the env setup script is in meta/classes/toolchain-scripts.bbclass Oct 04 09:57:16 ok thx, let me see if I can figure out where it goes wrong Oct 04 13:07:00 anyone having issues with numpy? Oct 04 13:07:00 https://gist.github.com/n-west/6825550 Oct 04 13:15:37 Crofton: I saw it but it vanished on rebuild Oct 04 13:15:44 ok Oct 04 13:16:37 just restart build? Oct 04 13:16:59 something like nuked tmpdir and sstate-cache Oct 04 13:17:29 could be it went away just by luck and it will come back in another build.. Oct 04 13:17:44 can you clear the sstate-cache for a single recipe? Oct 04 13:18:20 n|west: bitbake -c cleansstate recipe Oct 04 13:23:27 I switched to -j1 to build numpy and still got that build/temp.linux-i686-2.7/numpy/linalg/lapack_litemodule.o: could not read symbols: File in wrong format which is in fact in ARM 32-bit ELF Oct 04 13:24:03 it works on my pc :) Oct 04 13:24:12 is it using the right linker? Oct 04 13:24:20 and what TUNE_FEATURES are you suing Oct 04 13:24:27 not for an ARM ELF. It's using /usr/bin/ld Oct 04 13:24:37 TUNE_FEATURES = " armv7a vfp neon zynq" Oct 04 13:24:46 TUNE = " armv7a vfp neon zynq" Oct 04 13:24:56 TUNE_FEATURES* Oct 04 13:25:27 TARGET_SYS = "arm-oe-linux-gnueabi" Oct 04 13:25:43 I blame ubuntu Oct 04 13:26:19 affaff Oct 04 13:26:24 affirmativesdf Oct 04 13:26:27 ~. Oct 04 13:26:28 methinks ~. is not the escape sequence you're looking for. Oct 04 13:26:28 n|west: Error: "." is not a valid command. Oct 04 13:26:49 rofl Oct 04 13:27:21 ha, sorry. connection to irssi locked up Oct 04 13:27:29 doh Oct 04 13:27:49 but yes, TARGET_SYS is same Oct 04 13:27:54 ubuntu is a reasonable target Oct 04 13:28:11 we've seen some weird shit Oct 04 13:28:20 Crofton: are you targeting zc702 or zedboard? Oct 04 13:28:23 er Oct 04 13:28:33 I can't say in public :) Oct 04 13:28:49 but it shouldn't make any difference Oct 04 13:29:01 ah Oct 04 13:29:09 you have gfortran installed Oct 04 13:30:20 we think the problem is n|west has gfartran on his machine and I do not Oct 04 13:30:34 I suppose we need to club the numpy recipe harder Oct 04 13:32:58 that looks lik ethe culprit Oct 04 13:33:20 after removing gfortran setup.py picked up g77 Oct 04 13:33:39 then removing g77, it finally uses the oe native stuff Oct 04 13:33:48 err the right oe tools Oct 04 13:34:51 ok Oct 04 13:34:59 still some massing to do to clean up my machine before this actually succeeds Oct 04 13:35:04 but I'm at least headed in the right path Oct 04 13:35:07 should we make a bug in the yocto bugzilla? Oct 04 13:35:13 RP, ^^^ Oct 04 13:37:58 bluelightning, maybe? Oct 04 13:38:02 heyo, packaging! Oct 04 13:38:38 * bluelightning doesn't know anything about gfortran Oct 04 13:38:43 sorry Oct 04 13:39:26 for the record, I think pre-existing libblas also got in the way Oct 04 13:40:30 Crofton: I'm not sure we support fortran out the box Oct 04 13:40:57 Crofton: I'll take patches but probably not easily find anyone to debug it Oct 04 13:43:38 RP, it is a host contamination issue in a meta-oe recipe Oct 04 13:43:52 the question is does yp bugzilla support bugs from other layers Oct 04 13:44:42 Crofton: Depends really on the layer maintainer but in general, not really Oct 04 13:45:12 I am curious Oct 04 13:45:24 I'd hate to see a million bugzillas Oct 04 13:45:30 and unmaintained ones Oct 04 13:45:48 Crofton: well, it depends if someone is actually going to step up and work on the bugs, triage them and so on Oct 04 13:45:48 we had a meta-zynq/meta-xilnx issue creep in Oct 04 13:46:02 I agree Oct 04 13:46:13 Crofton: We do take bugs in there for meta-intel, meta-fsl-* and a few others which all do have active people Oct 04 13:46:23 I'd like to note the numpy issue someone Oct 04 13:46:28 somewhere damn it Oct 04 13:46:34 meta-oe does not have and I'd want some kind of commitment before we started taking bugs for it Oct 04 13:47:11 Maintaining a bugzilla takes a ton of time :( Oct 04 13:47:57 it seems like users are adding them to yp bugzilla regardless :) Oct 04 13:48:12 mainly I just wanted to start thinking about this Oct 04 13:48:34 Crofton: well, YP is as above and we may close things that are inappropriate Oct 04 13:48:44 sure Oct 04 13:49:05 but we need to remember that users do not see the edges as well as we do Oct 04 13:49:45 Crofton: I understand am happy to see it better documented or whatever else we can think of that can help Oct 04 13:50:10 ok Oct 04 13:50:15 lets go back to work :) Oct 04 13:50:35 Crofton: We do tend to step outside the bounds and fix things where we can too. I did fix the fortran compiler builds recently for example ;-) Oct 04 13:50:54 sure fortan is important to some freaks :) Oct 04 15:06:46 a bit off topic but... is this the right way to detect if the host system is 32 or 64bits in a linux driver ( "#ifdef CONFIG_PHYS_ADDR_T_64BIT" ) ? Oct 04 15:08:44 nicboul: Why do you want to check? Oct 04 15:09:23 the driver need to perform some asm stuff, and hence some register are different Oct 04 15:09:48 note that I did not write that driver, but I now need to kinda support it ;P Oct 04 15:11:05 if you know a better channel I could ask my question, I don't want to bother people with non-oe stuff ;) Oct 04 15:13:40 armlinux might be good. Oct 04 15:14:14 I was mostly asking because there's a bunch of stuff which you can run into even on 32 bit systems with things like LPAE. Oct 04 15:18:05 the thing is I installed debian 7.1 32bits on a 64bits machine Oct 04 15:18:34 and now it seems that CONFIG_PHYS_ADDR_T_64BIT is defined (does it should?) Oct 04 15:18:57 and hence the driver doesn't want to compile because it tries to do some asm stuff that only work on a 64bits OS Oct 04 15:19:00 it seems Oct 04 15:19:17 so Im a bit confuse to know if this define is the right one (it seems not ;( **** ENDING LOGGING AT Sat Oct 05 02:59:58 2013