**** BEGIN LOGGING AT Mon Mar 21 02:59:57 2011 Mar 21 04:25:30 03Denys Dmytriyenko  07master * r5b3df8cc52 10openembedded.git/conf/local.conf.sample: Mar 21 04:25:30 local.conf: add example to use external angstrom toolchain Mar 21 04:25:30 Signed-off-by: Denys Dmytriyenko Mar 21 04:25:41 03Denys Dmytriyenko  07master * r7af507bde1 10openembedded.git/recipes/meta/ (2 files in 2 dirs): Mar 21 04:25:41 external-toolchain-angstrom: use pre-built Angstrom toolchain Mar 21 04:25:41 * Use pre-built Angstrom toolchain available from [1] as external one Mar 21 04:25:41 [1] http://www.angstrom-distribution.org/toolchains/ Mar 21 04:25:42 Signed-off-by: Denys Dmytriyenko Mar 21 06:27:10 is there any alternative to make clean in oe, without loosing the source code? Mar 21 07:19:33 Hi Mar 21 07:19:56 getting udev errors when booting Angstrom with a custom kernel Mar 21 08:47:25 gm ant Mar 21 08:50:23 morning Mar 21 08:52:00 hi hrw Mar 21 08:52:18 hi woglinde, hrw, all Mar 21 08:57:18 hi effem Mar 21 09:04:06 hi mickeyl Mar 21 09:07:37 hi all Mar 21 09:08:46 hi bluelightning Mar 21 09:12:59 morning woglinde Mar 21 09:13:01 hi bluelightning Mar 21 09:33:01 good morning Mar 21 10:04:00 oh.. Mar 21 10:04:19 qemu-native from oe-core will have dependency on alsa Mar 21 10:04:29 as I see from oe-core ML Mar 21 10:05:16 so, now on build host I should have sdl+glx+alsa Mar 21 10:06:04 jay7 its not finally discussed Mar 21 10:08:51 well.. qemu have wav driver Mar 21 10:09:15 Jay7 sure Mar 21 10:09:26 imho this is enough for runtime testing purposes Mar 21 10:09:33 jay7 but do you know its working under arm the qemu devices? Mar 21 10:10:58 no, haven't checked Mar 21 10:15:52 hm.. Mar 21 10:16:02 other question wrt qemu Mar 21 10:16:20 what is purpose of non-native qemu then? Mar 21 10:16:30 I've thought we have only native Mar 21 10:19:34 where does one set no_console_suspend? new kernel config, change the code, kernel bootarg? Mar 21 10:19:36 hm.. or may be I was right and we have only native.. Mar 21 10:49:35 hey likewise Mar 21 11:03:09 hello eFfeM_work Mar 21 11:03:24 hi ant_work, how are you doing ? Mar 21 11:16:00 jay7 seems koen made the dessicion Mar 21 11:16:04 with qemu and alsa Mar 21 11:16:07 lunch now Mar 21 11:16:20 yeah.. Mar 21 12:32:05 Hello, I recently compiled the x11-image, and I seem to be having problems with Python (2.6.6) - the "subprocess" module is missing. Any ideas? Mar 21 12:36:35 davies11: I have "IMAGE_INSTALL += python-subprocess" in my rootfs.bb (which I based on console-image.bb) Mar 21 12:38:53 tasslehoff: That requires there to be a python-subprocess recipe though, no? Because when I try to bitbake it, it says "nothing supplies python-subprocess" Mar 21 12:41:19 davies11: if I understand correctly, what you list there is packages. do a "find -name python*.ipk" in the deploy dir. Mar 21 12:41:20 python-subprocess is defined in recipes/python/python-2.6-manifest.inc Mar 21 12:41:38 if I don't understand correctly, please correct me :) Mar 21 12:46:04 davies11: "bitbake python-subprocess" will fail (but adding it to IMAGE_INSTALL is ok, because it's runtime package name) Mar 21 12:46:20 JaMa: I see it has ${PN}-subprocess in the PROVIDES variable, but still I get "NoProvider: python-subprocess" Mar 21 12:46:31 ah I see Mar 21 12:46:41 davies11: or better add it to RDEPENDS_${PN} in recipe which needs it Mar 21 12:46:42 alright, I'll try that, thanks Mar 21 12:50:41 tasslehoff: You're right, I seem to already have in my deploy dir, it just wasn't installed.. weird. Thanks :) Mar 21 12:55:35 Hi, I am new to OE and trying to make an image derived from micro-image. When I add "iptables" to IMAGE_INSTALL it builds many deps related to x11/gtk that I don't want. How can I fix this? Mar 21 12:56:52 john_poulpe remove bluetooth from building Mar 21 12:57:02 but thats not so easy for a newbie Mar 21 12:57:17 john_poulpe besides the building the xstuff will not end in the image Mar 21 13:06:01 Ok, I'll try it. Just curious, how do you get this info? I tried bitbake -g, but no success. Mar 21 13:06:18 ? Mar 21 13:06:21 ah Mar 21 13:06:33 thats known by finding it out Mar 21 13:06:38 long time ago Mar 21 13:06:59 you have to check tasks stuff Mar 21 13:07:04 like base Mar 21 13:53:57 bluez4 is still selected after I remove bluetooth from MACHINE_FEATURES and DISTRO_FEATURES, what am I missing ? Mar 21 13:54:26 modules Mar 21 14:02:20 florian: good morning Mar 21 14:03:18 do we have a qmake guru around? Mar 21 14:04:08 http://pastebin.com/46BhrDUQ Mar 21 14:04:27 is what happened when I ran qmake on an omap3 system Mar 21 14:04:47 seems like the qmake recipe uses some OE vars from the cross build ... Mar 21 14:14:29 hi pb__ Mar 21 14:20:39 john_poulpe: bluez is a virus. Getting rid of it in distro images requires significant skills and tenacity... use the -g option to bitbake, and track down the dependencies to see what is pulling it in. Mar 21 14:21:12 mwester-laptop? Mar 21 14:21:23 I already said why xstuff is dragged in Mar 21 14:21:36 machine bla has bulez modules Mar 21 14:21:41 which drags in blued Mar 21 14:21:44 ups bluez Mar 21 14:21:50 which drags in gstreamer Mar 21 14:21:57 thats it Mar 21 14:22:15 Yep. Which I describe, tongue-in-cheek, as "virus-like" behavior. Mar 21 14:23:09 It's not very different than if a machine has a framebuffer, the recipes end up building and pulling in "wesnoth" Mar 21 14:24:02 Which is, of course, ridiculous. But apparently, if your machine can ever possibly have a bluetooth dongle plugged in, then it's good to build X11, gstreamer, and everything else. Mar 21 14:24:13 Which I have been trying -- unsuccessfully -- to fix. Mar 21 14:25:46 I'll continue to work on it since it seems that I'm not the only person who finds this broken. But I am so very curious why it is that this is not considered a problem for anyone else. Is it really the case that I'm the only person who has a device that lacks a framebuffer?? Mar 21 14:27:25 flash is getting cheaper Mar 21 14:28:22 mwester-laptop, you may also want to beat that drum with the oe-core guys Mar 21 14:28:25 My soldering skills are lacking, but even if I soldered in a few more chips, I don't think the typical user of the device would find that common. Mar 21 14:28:36 they are likely more motivated to come up with a solution Mar 21 14:28:59 I've mentioned that to them -- I'm really hoping that oe-core will fix this. Mar 21 14:29:36 I'll pull out what little hair I have left if they decide that gstreamer is oe-core! Mar 21 14:29:46 "USE-flags" discussion is on current TSC agenda IIRC.. Mar 21 14:30:10 oh no Mar 21 14:30:45 It's been mentioned that I should implement a machine feature for X11. I'm flattered that there are folks here who think my skills are actually adequate to do such a complex thing! Mar 21 14:30:53 but that's IMHO this problem.. someone wants bluez with gstreamer support someone doesn't Mar 21 14:31:30 JaMa: that latter thing is just a bluez packaging suckage. Mar 21 14:31:59 pb__: if the problem is that's pulled to target image.. Mar 21 14:32:12 JaMa: pardon? Mar 21 14:32:22 pb__: won't help with build time for bluez.. "bluetooth dongle plugged in, then it's good to build X11, gstreamer, and everything else." Mar 21 14:32:24 I haven't been able to "fix" it ("hack" might be a better word) by just changing bluez. So I think it's more than that. Mar 21 14:32:34 JaMa: no, that's not what I meant. the build time thing is a packaging suckage. Mar 21 14:32:41 or, perhaps more precisely, a recipe suckage. Mar 21 14:32:49 pb__: how? Mar 21 14:33:01 pb__: split to 2 recipes? Mar 21 14:33:03 JaMa: because bluez4 is a single monolithic recipe and there is no way to build just part of it. Mar 21 14:33:20 There's bluez-libs, no? Mar 21 14:33:26 bluez3 was packaged slightly better (though still not perfect) but the upgrade to bluez4 was a bit retrograde in that respect. Mar 21 14:33:54 pb__: ah now I see what you mean.. Mar 21 14:34:12 with bluez3, the gstreamer plugin was a separate recipe, so folks who didn't want it didn't have to build it (and hence didn't have to build its dependency chain) Mar 21 14:34:38 if it had been kept that way for bluez4 then this issue wouldn't have arisen, but (regrettably) it was all folded into a single .bb file Mar 21 14:34:55 There's really two problems -- one is the unncecessary stuff pulled into the image (that I've fixed), and the other is the build time -- that I have not been able to fix yet. Mar 21 14:35:04 mwester-laptop: yeah, you can build the libs separately, but sadly the libs alone are not quite enough for a "core" bluez system Mar 21 14:35:23 so, most people still end up building all the apps in order to just get the basic tools Mar 21 14:35:32 pb__: but that's again "USE-flags" at least as they are used in gentoo, without maintenance of 2-3 recipes building separate parts of same sources Mar 21 14:35:38 mwester-laptop: is your situation that you just plain don't want bluez at all? Mar 21 14:36:05 pb__: I wish to support bluetooth networking, at a minimum. Mar 21 14:36:06 JaMa: well, no. the point about having separate recipes is that, if your image or whatever depends on bluez-gstreamer-plugin, then it will get built. Mar 21 14:36:38 mwester-laptop: ah, ok. so you do also want the core bits of bluez, PAN and that kind of thing, but not gstreamer or headsets and that sort of thing? Mar 21 14:37:22 That's the compromise I think I must make, in order to fit it in. The NSLU2 lacks sufficient RAM and CPU to do the audio, and that is the most common device. Mar 21 14:37:33 right, sounds reasonable Mar 21 14:37:42 that's pretty much the situation I was also in last time I was looking at this stuff. Mar 21 14:37:58 I am fairly convinced that the right (perhaps only) way to fix it is to split up the monolithic bluez4 recipe. Mar 21 14:38:14 or go back to bluez3, which might or might not be an option for you Mar 21 14:39:21 I'm on teh final week of a four-week on-the-road trip, so I think I'll have to go back to this next week. I had hoped that I could get away with bluez-libs, but if that is not the case, I'll have to reconsider. Mar 21 14:39:36 no, bluez-libs isn't quite enough. you will also need bluetoothd and maybe hciattach. Mar 21 14:39:58 Ok, thanks for clearing that up. :) Mar 21 14:40:09 bluez-libs is enough to build other bluetooth-using apps (i.e. it gives you the libraries that you need to link against) but it is not sufficient on its own to give you a working bluetooth system at run time. Mar 21 14:40:51 kergoth did have a recipe at one point for a bluez4-apps package which would build on top of bluez4-libs. That would be a place to start if you wanted to split it up further. Mar 21 14:41:15 Hmmm... so bluez-libs is a dependency I might put into the SDK, but I would need bluez4 in order to get the base distro to support a dongle. Mar 21 14:41:23 right, exactly Mar 21 14:45:46 it would be really nice to clean up the bluez recipes Mar 21 14:46:17 do we still have a lot of stuff hanging around that requires bluez3? Mar 21 14:46:29 hardly anything to my knowledge Mar 21 14:46:40 bluelightning the cases stands for over 2 years now Mar 21 14:46:44 *g* Mar 21 14:46:45 angstrom and their derivates have had bluez3 blacklisted for ages Mar 21 14:46:46 I have up Mar 21 14:46:56 ups gave up Mar 21 14:47:20 I hadn't even thought it to be an option, so I have focused on bluez4. Mar 21 15:00:49 Focussing on bluez4 probably is the right thing to do for the long term, so I don't think you made any error there. Mar 21 15:19:48 once upon a time A ran into a guy that needed bluez3 because the equivalent thing in 4 didn't work Mar 21 15:19:52 but that was a while back Mar 21 15:20:18 Hopefully, whatever the problem was has been fixed in 4 by now :) Mar 21 15:50:53 Is anyone aware of any information on the web regarding the use OE images in commercial products? Mar 21 15:54:43 what do you mean? Mar 21 15:54:48 Wayne_, ? Mar 21 15:55:21 The legalities to be specific Mar 21 15:56:26 THe same as for any gpl based product Mar 21 15:56:50 since I think it is hard to have an image without any gpl sw :) Mar 21 15:58:40 I would say I'm relatively new to open source, anything I have done to date is basically prototyping so never really had to think too much about licensing Mar 21 16:00:28 it has been suggested to have a look at putting a prototype to market, so I had better swot up on all the different types of licenses. Mar 21 16:08:19 Wayne_: you had better talk to a lawyer then, rather than some folks on IRC... :) Mar 21 16:10:43 good call, no idea why the manager put this my way and not to some legal body? Might just bounce this one back to him Mar 21 19:38:46 https://gist.github.com/880013 - in case anyone else would find such a thing useful, not having it had been bugging me for a while Mar 21 20:29:35 kergoth: ah, interesting... Mar 21 20:34:31 denix: updated, has options to list cached repositories and sanitize their urls Mar 21 20:35:56 * kergoth might switch his oe project area script to use this rather than git-new-workdir Mar 21 20:42:04 kergoth: thanks. unfortunately, from what I can see, it seems that --reference only works with local caches... Mar 21 20:42:29 denix seems the libatomic-ops problem only occurs with older gcc Mar 21 20:42:37 with 4.5 even mips dont need it Mar 21 20:42:56 at least for pulse and cairo Mar 21 20:43:21 denix: that's correct, yes. if your cache is remote, there's no point in using this at all, just clone from the mirror url and git remote set-url origin if you want your clones to be initated from the mirror but really point upstream Mar 21 20:45:15 kergoth: hmm, will that pull from original uri when it's newer than the mirror? Mar 21 20:46:47 woglinde: which part of it? libatomic-ops not having primitives or cairo not building against libatomic-ops or even not looking for libatomic-ops? :) Mar 21 20:47:36 denix: not sure what you mean by that. a remote points at one place, period. set-url will change origin to point at upstream, and no operations against that remote will ever go against the mirror again, just the clone. Mar 21 20:47:58 the other option would be to have multiple remotes for mirror vs upstream, etc, but that's just a headache for day to day use and updates, really Mar 21 20:49:12 so an outdated mirror will cause a failure unless you use set-url but for only that package? Mar 21 20:49:32 denix hm? Mar 21 20:49:58 kergoth: right, so all the pulls will go to upstream, while the mirror is only used for initial clone. in most cases that's good enough. sometimes you may want to keep using the mirror though. but I guess playing with multiple remotes is not that bad :) Mar 21 20:50:06 denix with gcc-4.5 cairo uses gcc build in stuff Mar 21 20:51:15 woglinde: hmm, ok. even when libatomic-ops is present? does it set the corresponding define to "Intel"? Mar 21 20:51:33 even when it is present Mar 21 20:51:42 as I wrote Mar 21 20:52:01 when the two functions are found no other lock search is done Mar 21 20:52:27 hi i have some problems with the g_ether usb gadget. Mar 21 20:52:40 mdnneo in which case? Mar 21 20:52:48 ka6sox-home: not sure what you mean by that. if you clone from an outdated mirror, you just have old content, not a failure, until you update it and pull from it or pull from upstream directly Mar 21 20:53:12 i could start it with modprobe g_ether and configure with ifconfig usb0 ....up Mar 21 20:53:28 mdnneo sure Mar 21 20:53:34 but then i could not ping "myselfe" with the ip given in ifconfig Mar 21 20:53:44 * kergoth mutters Mar 21 20:54:02 mdnneo did you load the cdc driver on your hostside? Mar 21 20:54:08 kergoth whats up? Mar 21 20:54:29 * woglinde fighted with icedtea6-1.10 the whole day Mar 21 20:55:24 woglinde: monday :P Mar 21 20:55:57 can you give me some more details im pretty new to linux stuff. i just also include the g_cdc.ko gadget but i dont know how to load? Mar 21 20:56:20 mdneo on your device you need g_ether Mar 21 20:56:51 no your host you need the cdc_acm modul Mar 21 20:59:37 ah sorry now i think i know what you mean, as host i want to use my win 7 pc with the linux.inf rndis driver but if i attach my device to the pc it always just says unknown device. because of this i want to test g_ether on my device somehow so i tried to ping myself Mar 21 21:00:25 this works on my ubuntu virtualbox but not on my device Mar 21 21:03:25 so, oe.dev is slowly dying? has everyone switched to oe-core already? :) Mar 21 21:13:42 ok thanks for your help so far ... will check some things and come back =) .. cya Mar 21 21:34:24 hi woglinde Mar 21 21:43:00 hi gnutoo Mar 21 21:43:03 hi obi Mar 21 21:44:27 hi woglinde! Mar 21 21:46:45 woglinde, hi, I've some question on poky+oe-core etc... Mar 21 21:46:55 did everyone switch already? Mar 21 21:47:37 and is there some introduction on the subject in official docs like wiki Mar 21 21:47:43 *like the wiki Mar 21 21:48:07 because I don't remember the mails by heart Mar 21 21:48:26 and I would have to search them and read all which would be quite long Mar 21 21:59:03 I didnt switch Mar 21 21:59:13 khem wrote a short howto Mar 21 22:01:50 ok Mar 21 22:01:58 I'll read then Mar 21 22:02:14 I didn't switch either(since I ask it's obvious) Mar 21 22:03:20 the howto is on the mailing list? Mar 21 22:04:48 I shoudl do some test builds at soe point Mar 21 22:05:05 but I need a sane base to work from until we a really ready to cut vover :) Mar 21 22:05:24 ok Mar 21 22:07:06 that howto: http://sakrah.homelinux.org/blog/2011/03/using-openembedded-core-to-build-angstrom-for-qemu/ ? Mar 21 22:08:39 that looks like the url I have seen Mar 21 22:09:50 ok Mar 21 22:10:17 I wonder what JaMa cooked for SHR Mar 21 22:11:01 because I've to work principally with SHR and angstrom Mar 22 00:17:30 arm-angstrom-linux-gnueabi-gcc: libmpdemux/demux_rtp.cpp: C++ compiler not installed on this system Mar 22 00:17:51 getting that when mplayer tries to build, any ideas? Mar 22 00:18:16 it seems that if you compile a cpp file via gcc it complains, but if you use g++ it works fine Mar 22 00:23:53 vadmium, that's generally the case, yes. Mar 22 00:24:39 it works fine using my native gcc though Mar 22 00:25:13 and I used to be able to compile mplayer in OE, so something's changed, no idea what Mar 22 01:35:02 well correction: native gcc is fine as long as you give -lstdc++, but it certainly *compiles* fine **** ENDING LOGGING AT Tue Mar 22 02:59:57 2011