**** BEGIN LOGGING AT Thu Oct 14 02:59:57 2010 Oct 14 03:02:48 alias bitbake="schroot -c lucid -p -- bitbake" Oct 14 03:02:52 <3 Oct 14 03:10:36 hmm, need to work out the conf/site.conf situation wrt chroots Oct 14 04:08:23 opinion on including conf/site/${HOSTNAME}.conf after conf/site.conf? Oct 14 04:08:28 in bitbake.conf, of course Oct 14 04:33:59 03Graham Gower  07master * r0c1efbb0e1 10openembedded.git/recipes/galago/ (5 files in 3 dirs): (log message trimmed) Oct 14 04:33:59 galago: move to obsolete. Oct 14 04:33:59 libgalago doesn't build, and presumably hasn't since dbus 0.92 was in the tree. Oct 14 04:33:59 | ../libgalago/.libs/libgalago.so: undefined reference to `dbus_connection_disconnect' Oct 14 04:33:59 | collect2: ld returned 1 exit status Oct 14 04:33:59 | make[2]: *** [presence-feed] Error 1 Oct 14 04:33:59 Signed-off-by: Graham Gower Oct 14 04:34:01 03Graham Gower  07master * rbe5bc791c9 10openembedded.git/recipes/lua/ (3 files in 2 dirs): (log message trimmed) Oct 14 04:34:01 lua, lua-gtk2: move to obsolete. Oct 14 04:34:02 Lua fails to build. There are newer recipes (lua5.1) in tree, only Oct 14 04:34:02 lua-gtk2 uses this old recipe and nothing uses lua-gtk2. Oct 14 04:34:03 mipsel-oe-linux-gcc -march=mips32 -o ../../bin/luac Oct 14 04:34:05 -L/mnt/oe/tmp/sysroots/mipsel-oe-linux/usr/lib Oct 14 04:34:05 -Wl,-rpath-link,/mnt/oe/tmp/sysroots/mipsel-oe-linux/usr/lib -Wl,-O1 -Wl,-E Oct 14 04:34:05 03Jesse Gilles  07master * rd2e47ce600 10openembedded.git/recipes/ruby/ (ruby.inc ruby_1.8.7-p302.bb): Oct 14 04:34:06 ruby: update SRC_URI in ruby.inc Oct 14 04:34:07 Signed-off-by: Jesse Gilles Oct 14 04:34:07 Signed-off-by: Khem Raj Oct 14 04:34:07 03Vitus Jensen  07master * r8a88368dbe 10openembedded.git/recipes/htmldoc/htmldoc-gui_1.9.x-r1571.bb: Oct 14 04:34:08 htmldoc-gui_1.9.x: remove, there is no GUI code in developer snapshots Oct 14 04:35:00 ruby: fix socket extension compile Oct 14 04:35:00 * fixes building socket extension with ipv6 enabled Oct 14 04:35:00 Signed-off-by: Jesse Gilles Oct 14 04:35:00 Signed-off-by: Khem Raj Oct 14 04:35:01 03Graham Gower  07master * rf105fe72e2 10openembedded.git/recipes/ion/ (9 files in 2 dirs): Oct 14 04:35:01 ion: move to obsolete. Oct 14 04:35:02 This recipe has been marked BROKEN for 5 years or so. Oct 14 04:35:02 Signed-off-by: Graham Gower Oct 14 04:35:03 Acked-by: Frans Meulenbroeks Oct 14 04:35:03 (35 lines omitted) Oct 14 04:46:42 03Chris Larson  07master * r65ae48d1c7 10openembedded.git/classes/utils.bbclass: Oct 14 04:46:42 utils: fix popen->Popen reference Oct 14 04:46:42 Signed-off-by: Chris Larson Oct 14 04:46:45 03Chris Larson  07master * r130ff506b5 10openembedded.git/conf/bitbake.conf: Oct 14 04:46:45 bitbake.conf: add HOSTNAME variable Oct 14 04:46:45 Signed-off-by: Chris Larson Oct 14 05:12:37 does anyone know how to check if a nand flash is working or not Oct 14 05:12:58 how can we know for sure that our nand flash is not working Oct 14 05:18:29 ksinkar, hi Oct 14 05:38:49 aarti: Oct 14 05:38:55 u are here as well Oct 14 05:38:59 haha Oct 14 05:39:07 are u into embedded development? Oct 14 05:41:47 aarti: are u into embedded development? Oct 14 05:42:03 ksinkar, ya Oct 14 05:42:09 aarti: k Oct 14 05:42:38 aarti: what microcontroller? Oct 14 05:49:51 hi all, since so many days i m trying to clone the git for gumstix overo-oe but seems git is down Oct 14 05:50:02 any solution Oct 14 05:58:13 How can I get libusb1 into my rootfs without having anything directly depending on it? Oct 14 06:37:54 gm Oct 14 06:47:28 I'm trying to create a recipe for log4cxx 0.10.0. It seems to compile, but do_install fails with "will not overwrite just-created" for a header file. Does this indicate something wrong with the makefile? Oct 14 06:57:21 tasslehoff: yes, or with your do_install (if you have a custom one) Oct 14 07:05:07 Found and fixed, but this gives me the same issue as libusb. It's a lib, and I need to force it into my rootfs without anything depending on it. Oct 14 07:06:04 Guess I could create a dummy-recipe that uses log4cxx and libusb1, but it feels ... wrong Oct 14 07:16:18 good morning Oct 14 07:36:32 Good aftermoon! Oct 14 07:39:29 I found a problem in the defconfig of mini6410 which makes udhcpc fail. Should I submit a bug report? Oct 14 07:40:12 # CONFIG_PACKET is not set Oct 14 07:40:36 morninge Oct 14 07:41:17 or, not considered a bug... Oct 14 07:43:09 tasslehoff: you can just add the package that has the lib to your image Oct 14 07:44:10 various tasks/*bb files include libs Oct 14 07:45:39 eFfeM_work: but how would you solve that for libusb1. I tried adding to IMAGE_INSTALL and/or DEPENDS in my rootfs.bb, but it complains about a missing dependency chain. Oct 14 07:46:21 tasslehoff: with libusb1 the problem is more complex, guess the debian lib name mangling kicks inhere, don't know too much about that Oct 14 07:46:34 (saw the error too) Oct 14 07:56:25 eFfeM_work: I got the same error message when I tried log4cxx Oct 14 07:56:26 now I've made a dep-dummy recipe with a cpp-file that does a bit of libusb/log4cxx stuff... Oct 14 07:56:58 03Koen Kooi  07org.openembedded.dev * r5e21955af7 10openembedded.git/recipes/powervr-drivers/ (2 files in 2 dirs): omap3-sgx-modules: make patch apply with all versions of patch Oct 14 07:57:08 tasslehoff: you definitely do not need code in that recipe, all is driven by DEPENDS/RDEPENDS Oct 14 07:57:51 eFfeM_work: thanks. Oct 14 07:58:03 yw Oct 14 09:05:21 hi guys .. i am building meta-toolchain but its missing mkimage to generate uImage from kernels how would i add this to the meta-sdk ? Oct 14 09:05:50 How should a recipe without sources that just has to bring in a couple of dependcies look? I tried just adding a DEPENDS and a PR, but that doesn't work. Oct 14 09:11:07 03Koen Kooi  07org.openembedded.dev * r735591c9c8 10openembedded.git/recipes/gnome/gnome-bluetooth_2.30.0.bb: gnome-bluetooth 2.30.0: bump PR for introspection change Oct 14 09:11:12 03Koen Kooi  07org.openembedded.dev * r99561d6fcc 10openembedded.git/classes/gnome.bbclass: Oct 14 09:11:12 gnome bbclass: disable introspection Oct 14 09:11:12 * introspection doesn't work in a cross environment Oct 14 09:11:13 03Koen Kooi  07org.openembedded.dev * recdc961a9e 10openembedded.git/recipes/atk/atk_1.30.0.bb: atk 1.30.0: bump PR for introspection change Oct 14 09:11:23 03Koen Kooi  07org.openembedded.dev * r80db0cce81 10openembedded.git/recipes/gstreamer/ (gstreamer.inc gstreamer_0.10.30.bb): gstreamer: bump PR for introspection change Oct 14 09:12:35 eFfeM_work: welcome back from split Oct 14 09:14:05 have you checked about legacy-staging recently? I still see 3 recipes needing care Oct 14 09:14:29 butsurely there are many more remaining Oct 14 09:21:05 Hi, we do have a very strange problem with lxde-common. One of our rootfs images depends on it (DEPENDS/IMAGE_INSTALL), but the lxde-common ipks are not built and so building the rootfs image fails with, because the ipk does not exists Oct 14 09:21:05 It seem that work/lxde-commn-0.5.0-r0/staging-pkg is not complete. Cleaning lxde-common and retriggering the rootfs image built again is so far the only workaround, which is not very nice. Oct 14 09:21:05 Any ideas? Oct 14 09:21:53 eFfeM_work: hm. wouldn't it solve my issue to put RDEPENDS = "libusb1" in myrootfs.bb? instead of using a dummy-recipe. Oct 14 09:22:38 ant_work: actually also did a reboot (and yeah at some point there were only 8 or so of us Oct 14 09:23:01 tasslehoff: if it works in a dummy recipe it'll work in myrootfs.bb Oct 14 09:23:08 I'd say Oct 14 09:23:41 ant_work: there are many more recipes that have legacy staging, but these are old ones that are rarely build (or older versions etc) Oct 14 09:24:16 ok, I did remove unpinned by adjusting the most recents Oct 14 09:24:29 now we can remove preferred-gpe-versions too Oct 14 09:24:43 fine with me Oct 14 09:24:48 lot of preferences Oct 14 09:25:09 florian gave an implicit ack ;) Oct 14 09:25:20 not sure if this is of any relevance but: grep -w do_stage recipes/*/* | wc gives 464 matches Oct 14 09:25:26 RDEPENDS simply means "trust me and install this, cause I will need it to run"? Oct 14 09:25:52 eFfeM_work: I have 3 remaining (building console, opie, x1, x11-gpe images) Oct 14 09:25:53 tasslehoff: maybe not the first part, but the 2nd part yes (I need this to run) Oct 14 09:26:40 eFfeM_work: 2 of them are qt/opie Oct 14 09:26:47 ant_work: there are two more causes: one is because the recipe is old, the other one is because it is a recipe (whcih might be newer) that has DP = -1 for your machine Oct 14 09:27:03 but I'd say, mainstream versions are 'clean' Oct 14 09:27:22 I just built angstrom and minimal, no idea about other distros Oct 14 09:27:47 btw we have to remove that sharprom-compatiblt too... Oct 14 09:28:06 I was away, freezing in Koeln, no time yet:/ Oct 14 09:28:15 perhaps this night Oct 14 09:28:32 ant_work: you're building angstrom ? Oct 14 09:28:45 yes Oct 14 09:28:51 thought so Oct 14 09:29:06 sometimes minimal too Oct 14 09:29:20 usually with uclibc Oct 14 09:29:20 try minimal and see how many you get Oct 14 09:29:25 e.g look at python-pycairo Oct 14 09:29:33 ok, I'll do Oct 14 09:29:47 eFfeM_work: it pulled in libusb1, but not the libs from log4cxx, but it's a start Oct 14 09:29:55 1.4.0 has a do_stage, 1.8.0 does not and has DP = -1 but a DP_angstrom = 1 Oct 14 09:30:18 these things are typical Oct 14 09:30:23 btw, removing the do_stage I had some doubts ... STAGING_* vars are evl in doinstall, I know Oct 14 09:30:35 but in do_compile? I think these are fine there Oct 14 09:31:03 s/evl/evil/ Oct 14 09:32:15 eFfeM_work: pls see http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=4af226e94d43549ddfaec09fd13980e434baf1b6 Oct 14 09:32:43 typical OE pattern: someone creates a recipe, gives it a DP = -1 because it needs more testing or he/she is not sure about it, maybe add a local override then forgets about it; python-pycairo 1.8.0 is already there for more than a year, why should it have DP = -1 in the first place? guess in a year it should be tested and fixed Oct 14 09:32:59 heh Oct 14 09:33:15 I feel guilty having added some kernels with DP = -1 Oct 14 09:33:40 * eFfeM_work feels DP is overused (and abused) Oct 14 09:33:46 but ignoring what people outside are doing, I cannot remove them :/ Oct 14 09:34:23 yeah, it is probably somethign to be discussed at oedem too, but I doubt whether it will get hands onto each other Oct 14 09:34:52 I think the solution is to do release say every 6 months Oct 14 09:35:06 so our friends in the wildd can use a relese Oct 14 09:35:24 and .dev keeps cleaning Oct 14 09:35:52 ant_work: wrt your patch, not sure if STAGING_BINDIR_NATIVE etc are the right names to use. I saw fasad and noor replacing these with other names Oct 14 09:36:19 that's why I'm asking... Oct 14 09:36:41 don't recall details and dont have time to look it up right now, sry Oct 14 09:37:04 np Oct 14 09:37:08 btw personally i'm not too happy if I see install lines in do_compile Oct 14 09:37:25 he..exactly Oct 14 09:37:44 actually trying to find out why gcc-cross-sdk builds nicely for me under ubuntu 10.04 but not for a customer under opensuse 11.3 Oct 14 09:37:48 beside of this, some recipes are lacking INC_PR Oct 14 09:37:53 and ofc this is a version of a while ago Oct 14 09:37:58 this would be another round of patches Oct 14 09:38:00 some ??? most! Oct 14 09:38:07 after adding an RDEPENDS to log4cxx, I find the following in deploy: http://pastebin.ca/1961761, but the library isn't added to my rootfs. Oct 14 09:38:12 :) Oct 14 09:38:44 909 inc files of which 235 have an INC_PR Oct 14 09:38:55 eFfeM_work: first, remove the obsolete/unused, hen we can fix the INC thing Oct 14 09:39:12 * ant_work cannot type today Oct 14 09:39:30 yeah, agree, but still not fully recovered from the burn woulds I got from the flames last august :-( Oct 14 09:39:54 but i am willing to support any cleanup action Oct 14 09:39:56 i.e. some inc files are now superfluous: just two reipes in dir (_git and _PV) Oct 14 09:40:16 heh, flames last august? Oct 14 09:40:23 in the russia? Oct 14 09:40:37 03Koen Kooi  07org.openembedded.dev * rc68c964ec0 10openembedded.git/recipes/gnome/epiphany_2.30.2.bb: epiphany: fix EXTRA_OECONF Oct 14 09:41:01 * eFfeM_work is in NL (and they were virtual flames) Oct 14 09:41:19 as in the mailing list flame? Oct 14 09:41:45 yesss Oct 14 09:42:07 what a quiz Oct 14 09:43:37 got flamed for removing files; got flamed for doing a bitbake world and post about it, got flamed because i proposed to make it mandatory to provide a reason when NAK-ing a patch; actually have several more of these Oct 14 09:44:48 real deal :) Oct 14 09:45:08 and yeah, i admit I was a little bit too agressive removing old versions but some of the responses were outright rude Oct 14 09:45:50 eFfeM_work: I'd say, ignore the past and go ahead. We are in a 'magic' moment, being many historically active devs are now busy with other stuff and apart one, nobody complains ;) Oct 14 09:46:21 major argument against removal was "someone somewhere out there might have an out-of-tree recipe that uses this" Oct 14 09:47:10 actually if it is an out-of-tree user that does not tell us and does not contribute I don't care too much (they then should learn to use git and overlays), but that is my $ 0.02 Oct 14 09:47:24 eFfeM_work: maybe there are overlays in a parallel universe too Oct 14 09:47:47 how can we know if they don't knock? Oct 14 09:50:47 git tag working-config; git pull --rebase Oct 14 09:51:01 if it doesn't work, git checkout working-config and compare :) Oct 14 09:51:20 this is my five cents for not keeping really old recipes Oct 14 09:51:32 or use bbappend Oct 14 09:52:02 what's the point for such recipes in .dev anyway Oct 14 09:52:14 Is it possible within a recipe to force the rebuild of a depend's package even if it's PR isn't ticked up from it's last build? Oct 14 09:52:25 ant_work: I have overlays here, but we want to run a stable system, so we don't move with head every day, we sync every once in a while only Oct 14 09:52:43 and if a recipe is removed from head, we just put a copy in our overlay, no big deal Oct 14 10:07:09 Any wizards that can help me add liblog4cxx to my rootfs? I'm out of ideas. Oct 14 10:08:46 tasslehoff: how is packaged that liblog* ? Runtime checks the name of 'packaged' files Oct 14 10:10:37 ah, I see your pastebin: liblog4cxx10 Oct 14 10:10:45 ant_work: yep :) Oct 14 10:10:52 RDEPENDS should point to it Oct 14 10:11:43 I missed the start of your question: do you want it as runtime deps? Oct 14 10:12:56 ant_work: yeah. I compile apps that use libusb1 and log4cxx, but I do it with an SDK, so nothing in my rootfs-build depends on the libraries. Oct 14 10:14:24 RDEPENDS += "libusb1 log4cxx" compiles, but doesn't give me log-libs in my rootfs. If I put liblog4cxx10 in there instead, it complains about Missing or unbuildable dependency chain. Oct 14 10:14:45 s/log4cxx/liblog4cxx10/ Oct 14 10:14:49 and retry Oct 14 10:14:55 hm Oct 14 10:15:38 ant_work: same error. Oct 14 10:17:41 a couple of weeks ago it worked just doing IMAGE_INSTALL += "libusb1", but something has changed recently Oct 14 10:17:53 git bisect ? Oct 14 10:18:07 me too I'm not expert in debian-renaming, but if the ipk is called liblog4cxx10_0.10.0-r0.6_armv7a.ipk I'd expect this is the name Oct 14 10:19:05 tasslehoff: i've done a few commits that influence RDEPENDS maybe one of these causes this Oct 14 10:21:22 tasslehoff: i suggest doing a git checkout for 723862ee9947bfd8a14817b6df8c41da41437594 and try if it works wiht that, that is just before my RDEPENDS commits Oct 14 10:21:28 tasslehoff: where are you adding your IMAGE_INSTALL and/or RDEPENDS_PN ? Oct 14 10:21:39 which all have RDEPENDS -> RDEPENDS_${PN} in the commit message Oct 14 10:21:47 ant_work: I think maybe the names comes from "pkgdata/armv7a-angstrom-linux-gnueabi/log4cxx", at least if I judge by libusb1 Oct 14 10:22:01 eFfeM_work: will do. Oct 14 10:22:21 ant_work: in myrootfs.bb Oct 14 10:22:33 which is an image Oct 14 10:22:37 ok Oct 14 10:22:48 then you have a lot of alternatives :) Oct 14 10:23:01 didn't have any _${PN}, though Oct 14 10:23:33 tass and if the above commit works, move to 1611e2faf1f5b5bb4f97ac9500396716a2c76c23 and see if that one still works (that is after my RDEPENDS changes) Oct 14 10:23:49 in the image, no need for PN Oct 14 10:24:56 try EXTRA_IMAGEDEPENDS += " " Oct 14 10:25:08 tasslehoff: there are also some chagnes in image.bbclass from Chris about 4 days ago Oct 14 10:25:13 or straight = Oct 14 10:25:24 like this one: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=ea01e75217b5a7894fc387ce9d61876df4c4dbcd Oct 14 10:25:30 that could also affect things Oct 14 10:33:25 eFfeM_work: both your commits were ok Oct 14 10:33:48 then move to check out the patches from chris Oct 14 10:34:05 way ahead of you :) Oct 14 10:34:36 eg this one: ea01e75217b5a7894fc387ce9d61876df4c4dbcd Oct 14 10:35:30 EXTRA_IMAGEDEPENDS += "PACKAGE-NAME" should be immune of runtime-deps issues Oct 14 10:35:50 bbl Oct 14 10:36:01 true; btw there aer some more image.bbclass changes round taht time Oct 14 10:37:05 eFfeM_work: that one failed Oct 14 10:37:18 tasslehoff: can you try the one before that Oct 14 10:37:57 afk 4 lunch Oct 14 10:38:18 eFfeM_work: on it. (hope git checkout ea01e75217b5a7894fc387ce9d61876df4c4dbcd~1 was correct) Oct 14 10:41:27 eFfeM_work: that worked, so chris commit is the one that breaks it for me. Oct 14 10:41:51 the Q is if that makes it a bad commit, or if I don't write my recipes right :) Oct 14 10:50:48 hi Oct 14 11:08:51 eFfeM_work: after reverting that commit, I could add libusb1, log4cxx and libqt to IMAGE_INSTALL and find them in my image afterwards. Oct 14 11:14:11 tasslehoff: cool you found the cause, I suggest talking to kergoth as it was his patch Oct 14 11:14:43 kergoth_: want to talk to me? :-) Oct 14 11:14:54 tasslehoff: maybe you need to add to PACKAGE_INSTALL instead Oct 14 11:15:27 tasslehoff: i think (not sure though) he is in the US so guess he is asleep Oct 14 11:15:47 I did a recipe for lib4cxx 0.10.0 that I could share. Should I just submit it to the mailing list as a patch? Oct 14 11:15:50 ok Oct 14 11:16:19 tasslehoff: please do (as patch with commit msg etc) Oct 14 11:24:11 there's a machine ts72xx in OE, which should be compatible with ts7200, ts7250 and ts7260 SBCs and now I would like to add support for ts7400, which is almost the same as ts72xx SBCs, but have some minor differencies, to get it working in .dev as it is, there's just one kernel patch needed, for the SD card Oct 14 11:24:33 I think, that it makes no sense to create ts74xx machine just for this Oct 14 11:28:56 ynezz: you might need a different default configuration for the kernel as well? can you test the patch with ts72xx? Oct 14 11:30:18 no, it's runtime configuration Oct 14 11:30:22 no config change Oct 14 11:31:58 this should be the only change to the ts72xx patchset already in OE - http://pastebin.com/kULdfTf0 Oct 14 11:32:28 oh, no file, it's in arch/arm/mach-ep93xx/ts72xx.c Oct 14 11:33:01 hm, best thing is probably to ask at the mailing list an hope that the maintainer of ts72xx is reading it Oct 14 11:33:12 it's me I think :) Oct 14 11:33:22 nobody else is doing work on the ts72xx in OE Oct 14 11:33:47 I'm just asking how to handle this scenario, I would like to add ts74xx and maybe ts73xx support to OE also Oct 14 11:34:09 it's same base architecture, ts7300 does have only additional FPGA Oct 14 11:34:47 but I don't see a point to have custom machine for every of their product line Oct 14 11:35:04 maybe I should rename ts72xx to ts7234 :) Oct 14 11:35:15 yes Oct 14 11:35:32 or make ts7xxx.inc as base and include it into ts72xx, ts73xx, ts74xx Oct 14 11:35:58 hehe Oct 14 11:36:12 it might happen, that I will need expansion for every type of their product line Oct 14 11:36:34 SRC_URI_append_ts73xx = "fpga-related.patch" Oct 14 11:37:19 looks like I should ask on the mailinglist Oct 14 11:37:36 ynezz: and you cant make kernel which works on both? Oct 14 11:37:55 I can, maybe for both threee Oct 14 11:37:56 ynezz: what kind of board/system is this? Oct 14 11:38:13 eFfeM_work: ep93xx, embeddedarm.com Oct 14 11:38:25 ynezz: make kernel which work on 72xx 73xx 74xx and you will not have to worry about OE Oct 14 11:38:58 but for example ts74xx has 3 serial ports, ts72xx just 2 etc. Oct 14 11:39:24 there might be more differencies and I would like to be prepared for that from start Oct 14 11:40:05 eFfeM_work: http://www.embeddedarm.com/products/arm-sbc.php#ts-7300-fpga-series Oct 14 11:40:23 eFfeM_work: http://www.embeddedarm.com/products/arm-sbc.php#ts-7200-200mhz-series Oct 14 11:40:41 eFfeM_work: http://www.embeddedarm.com/products/board-detail.php?product=TS-7400 Oct 14 11:41:11 hurray Oct 14 11:41:14 it's almost the same base, but for example for ts73xx it might be possible to use video output Oct 14 11:41:18 latest java thingies build Oct 14 11:42:02 woglinde: nice Oct 14 11:46:56 ynezz: nice ones, but I think the fpga on the 7300 is a little bit too slow and maybe too small for us Oct 14 11:47:03 ynezz: creating a config for each machine and a common include is ok, has been done e.g. for Zaurus family, but has a disavantage (think about many machine overrides in the recipes) Oct 14 11:48:15 * eFfeM_work wants a bemicro sdk to play with but can't get them yet: http://www.arrownac.com/offers/altera-corporation/altera-bemicro/ Oct 14 11:48:41 cyclone iv, can run nios etc Oct 14 11:48:46 and very cheap Oct 14 11:50:44 it's ep93xx + fpga Oct 14 11:50:48 not just fpga :) Oct 14 11:51:14 pushed Oct 14 11:51:25 03Henning Heinold  07org.openembedded.dev * rf43eee2945 10openembedded.git/recipes/icedtea/ (13 files in 2 dirs): Oct 14 11:51:26 icedtea6-native: update to version 1.7.5 Oct 14 11:51:26 * remove 1.7.3 version because of security bugs Oct 14 11:51:26 * explicit disable build of the new browser plugin Oct 14 11:51:31 03Henning Heinold  07org.openembedded.dev * r97fcfd8423 10openembedded.git/recipes/openjdk/ (openjdk-6-release-6b18.inc openjdk-6_6b18-1.8.bb): Oct 14 11:51:31 openjdk: update to version 1.8.2, because of security issues Oct 14 11:51:31 * bump PR Oct 14 11:51:36 ynezz: I know Oct 14 11:51:50 ep93xx... I hate its fpu Oct 14 11:53:10 ant_work: ok, say I'll make ts7xxx.inc and include it in ts72xx.conf, would it be possible to use both _append_ts7xxx and _append_ts72xx? (don't know how's it called, variable expansion?) Oct 14 11:54:08 overrides? Oct 14 11:54:19 ah, ok, overrides Oct 14 11:54:59 ynezz: no, you have to explicit one by one Oct 14 11:55:22 in your example only _ts72xx Oct 14 11:55:34 hm did someone test directfb with qemu? Oct 14 11:55:50 ant_work: this is what I would like to avoid :) Oct 14 11:56:31 maybe specify some variable MACHINE_FAMILY="ts7xxx" in ts7xxx.inc Oct 14 11:57:18 for example kernel is from 95% same for ts7234 boards Oct 14 11:57:59 and just small addons for ts73xx and ts74xx Oct 14 11:58:15 hrw: hm, fpu, I'm lucky I don't use it :) Oct 14 11:58:19 ynezz: and vendor does not care about mainline? Oct 14 11:58:39 ynezz: check gcc 4.3.3/4.3.4 in OE - they have all what is needed Oct 14 11:58:55 ynezz: but also read commit logs Oct 14 12:03:07 hrw: are you kidding? :D Oct 14 12:03:31 ;D Oct 14 12:03:54 they ported netbsd instead of giving some hw/money to Lennert Buytenhek Oct 14 12:04:19 morning Oct 14 12:04:21 he's the one who started moving the stuff to mainline Oct 14 12:04:27 as far as I remember Oct 14 12:04:39 they simply don't care Oct 14 12:04:59 they're happy with some mega stable 2.6.24, booting in 1.1 seconds Oct 14 12:06:04 what the hell is this Oct 14 12:06:06 LDFLAGS_append = "" Oct 14 12:07:19 ynezz: theer is recent work about SOC_FAMILY, check in ML Oct 14 12:10:44 woglinde, hmm Oct 14 12:12:10 woglinde triggered by your LDFLAGS did a grep for "" Oct 14 12:12:22 what about: Oct 14 12:12:24 qi/qi-ubi_git.bb:PROVIDES = "" Oct 14 12:12:35 stupid smiley Oct 14 12:12:58 mono/mono-native_2.6.3.bb:SRC_URI += "" Oct 14 12:13:28 matchbox-wm/matchbox-wm_1.0.bb:RDEPENDS_${PN} = "" Oct 14 12:13:55 forcing RDEPENDS to ""? maybe the stuff get packaged elsewhere but does not look too sound Oct 14 12:14:50 also puzzled by this: Oct 14 12:14:51 acpid/acpid.inc:EXTRA_OEMAKE = "" Oct 14 12:16:59 okay will push directfb now Oct 14 12:18:29 ynezz: http://docs.openembedded.org/usermanual/html/commonuse_new_machine.html Oct 14 12:18:31 is SRC_URI initialised as "", or in ohter words, is this useful Oct 14 12:18:32 meta/cross-linkage_1.0.bb:SRC_URI = "" Oct 14 12:19:40 ant_work: The use of SOC_FAMILY as an override is currently a distribution or local setting. Oct 14 12:19:48 ant_work: how to interpret this? Oct 14 12:20:11 heh... debate is still open I guess Oct 14 12:20:18 ah :) Oct 14 12:22:04 03Henning Heinold  07org.openembedded.dev * r9e605d5dca 10openembedded.git/recipes/directfb/ (4 files in 3 dirs): Oct 14 12:22:04 directfb: update to version 1.4.6 Oct 14 12:22:04 * ts-lib patch is applied upstream Oct 14 12:22:04 * remove older minor versions Oct 14 13:20:15 anyone a pointer on how to fix a failed sanity test in a .pc file (pkgconfig path) Oct 14 13:23:58 anyone used an OE-built log4cxx before? everything compiles fine and dandy now, but when I try to use it my application just hangs. Oct 14 13:25:49 is anyone aware of problems with lxde-common, where the .ipk s are NOT built but doing bitbake -c build lxde-common claims to have nothing to do? Oct 14 13:42:33 effem_work: and you checked the obvious? (not inheriting hte class) ? Oct 14 13:43:36 Tartarus: it does, but it only does part of the job, this is not git head, but it is a good plan to peek into the class Oct 14 13:44:37 OK Oct 14 13:44:44 Tartarus: thanks for the hint, this version did not change all paths Oct 14 13:44:47 Check the .pc file and make sure it's not a new case that the class needs to fix up Oct 14 13:44:49 will update the class file! Oct 14 13:44:50 I've hit those from time to time too Oct 14 13:45:07 i think the latest class will fix it Oct 14 13:45:46 guys, if my build has a python script that requires some special module, how do I specify that correctly? I added pyton-native to DEPENDS and I also added the module, but there is no native package for the modules... and during the build process the script is not finding that module Oct 14 13:46:57 i thought there are native packages for modules Oct 14 13:47:05 * eFfeM_work peeks Oct 14 13:47:18 mm, maybe I missed something? Oct 14 13:48:57 I'm not on latest oe.dev, couple of months behind.. don't see any native python module packages; do you have them? Oct 14 13:48:59 Jin^eLD: can't find it but don't have a full build here, could be I am mixing up and what I was thinking about was a perl module Oct 14 13:49:45 Jin^eLD: what module did you need ? Oct 14 13:50:11 lxml Oct 14 13:51:03 there is no native flavour of that one but you could try adding Oct 14 13:51:04 BBCLASSEXTEND = "native" Oct 14 13:51:08 to the lxml recipe Oct 14 13:51:26 pyrex also does that Oct 14 13:52:05 or create a native recipe e,g pygobject has a native variant Oct 14 13:52:22 and if you solve things, please submit a patch Oct 14 13:52:26 I see, so I really have to add a native .bb Oct 14 13:52:28 ok.. Oct 14 13:52:54 I need to finally update to latest oe.dev and then go through my changes and submit patches, I think I have a bunch of things in the pipeline Oct 14 14:00:17 btw wrt the advise above: eFfeM is actually a python n00b Oct 14 14:00:48 hehe, well, I added a native package for python-lxml and it is building right now.. Oct 14 14:00:52 Jin^eLD: instead of making a native recipe first try if you can just use BBCLASSEXTEND (unless your tree is too old and does not have BBCLASSEXTEND yet) Oct 14 14:01:03 my tree seems too old Oct 14 14:01:16 the pyrex package you told me as exampl does not have the EXTEND thing either Oct 14 14:01:23 so I just added another native package Oct 14 14:01:54 yes, seems the best solution Oct 14 14:04:30 hrmph, figures tasslehoff would leave Oct 14 14:04:35 i can't reproduce his behavior Oct 14 14:04:57 IMAGE_INSTALL_append = " nano" in my local.conf results in it being in the micro-image RDEPENDS, and in the bitbake -g for micro-image Oct 14 14:13:22 kergoth he had issues with libs, i feel packages are ok (didn' thave problems with that myself either) Oct 14 14:16:25 03Tom Rini  07org.openembedded.dev * r1315d3eea6 10openembedded.git/recipes/freetype/ (16 files in 5 dirs): (log message trimmed) Oct 14 14:16:25 freetype: Drop old recipes Oct 14 14:16:25 All of these versions have various security issues to them and Oct 14 14:16:25 are not pinned. Remove. While in here, rename files to freetype. Oct 14 14:16:25 Acks apply to the removal portion. Oct 14 14:16:26 Acked-by: Frans Meulenbroeks Oct 14 14:16:27 Acked-by: Martin Jansa Oct 14 14:21:43 hmmm. Oct 14 14:21:48 i think I might see the issue Oct 14 14:23:28 eFfeM_work: its packaging renaming. Oct 14 14:23:30 kergoth_: in RDEPENDS shouldn't it be liblog4cxx10 (recipe is log4cxx)? Oct 14 14:23:32 PACKAGE_INSTALL gets renamed Oct 14 14:23:40 RDEPENDS shouldn't, so when i made it use PACKAGE_INSTALL, boom Oct 14 14:23:49 ah Oct 14 14:23:57 * kergoth_ should have seen that Oct 14 14:24:07 kergoth_ ah, ok didn't understand the issue but sounds ok Oct 14 14:24:41 * eFfeM_work thought it could be related to my RDEPENDS -> RDEPENDS_${PN} changes that's why it drew my attention Oct 14 14:25:37 nah, i reverted the image change to -> RDEPENDS_${PN}, since it conceptually it doesn't fit for recipes which aren't emitting any packages Oct 14 14:25:53 * kergoth_ fixes the rdeps Oct 14 14:25:54 kergoth_ those things happen; as my grandpa used to say "people who do things, make mistakes; I know people who do not make mistakes" Oct 14 14:26:05 heh, well said Oct 14 14:26:16 and quite apt, considering .dev Oct 14 14:26:57 we use here nice proverb "who doesn't do anything, doesn't break anything" Oct 14 14:31:31 * kergoth_ mutters Oct 14 14:38:00 okay, that fix seems to work, but verifying a successful micro-image first Oct 14 14:38:03 heh Oct 14 14:51:42 Sigh Oct 14 14:52:04 I wish it was less duplication to do slightly different image types Oct 14 14:52:23 * Tartarus wonders if doing: IMAGE_CMD_ext2.bz2.u-boot = "${IMAGE_CMD_ext2.bz2} ; mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C gzip -n ${IMAGE_NAME} -d ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.bz2 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.bz2.u-boot" would cause screams Oct 14 14:58:23 03Sean Cross  07master * r051d975083 10openembedded.git/recipes/c-ares/ (0001-fix-configure.ac.patch c-ares_1.5.3.bb): Oct 14 14:58:23 c-ares: Fix configure.ac Oct 14 14:58:23 Get configure to work with our version of autoconf by fixing Oct 14 14:58:23 the syntax of configure.ac Oct 14 14:58:23 Signed-off-by: Khem Raj Oct 14 14:58:39 03Simon Busch  07master * rdb0841afe8 10openembedded.git/recipes/libgee/libgee.inc: Oct 14 14:58:39 libgee: remove unnecessary dependency on gobject-introspection Oct 14 14:58:39 Signed-off-by: Simon Busch Oct 14 14:58:39 Signed-off-by: Khem Raj Oct 14 14:58:39 03Simon Busch  07master * r0ce58c8454 10openembedded.git/recipes/libgee/ (libgee.inc libgee_0.5.2.bb libgee_0.6.0.bb): (log message trimmed) Oct 14 14:58:39 libgee: define common INC_PR and use it in all specific version recipes Oct 14 14:58:40 Until now there is now way to indicate that the libgee.inc common part of libgee has Oct 14 14:58:40 changed - the PR is only defined in the specific version recipes. This adds the INC_PR var Oct 14 14:58:41 to to the common libgee.inc and use it in the specific version recipes. Oct 14 14:58:41 INC_PR is initial set to the highest value of both version 0.5.2 and 0.6.0. Oct 14 14:58:42 Signed-off-by: Simon Busch Oct 14 15:52:56 hmm... anybody can tell me where PKG_CONFIG_DIR is supposed to be set for target builds? libusb fails with the following error: Oct 14 15:52:59 ERROR: Logfile of failure stored in: /OE/tmp/work/armv7a-oe-linux-gnueabi/libusb-0.1.12-r4/temp/log.pkgconfig_sysroot_preprocess.23950 Oct 14 15:53:02 Log data follows: Oct 14 15:53:04 | install: missing file operand Oct 14 15:53:07 | Try `install --help' for more information. Oct 14 15:53:19 and it looks like that is due to PKG_CONFIG_DIR being empty Oct 14 15:53:31 bitbake@gonzales ~/tmp/work/armv7a-oe-linux-gnueabi/libusb-0.1.12-r4/libusb-0.1.12 $ bitbake -e libusb | grep PKG_CONFIG_DIR Oct 14 15:53:34 install -d /OE/tmp/work/armv7a-oe-linux-gnueabi/libusb-0.1.12-r4/sysroot-destdir/${PKG_CONFIG_DIR} Oct 14 15:53:37 cat $pc > /OE/tmp/work/armv7a-oe-linux-gnueabi/libusb-0.1.12-r4/sysroot-destdir/${PKG_CONFIG_DIR}/$pcname Oct 14 15:53:44 hold, will take care of it Oct 14 15:53:58 ahh, ok :-) Oct 14 15:55:41 03Chris Larson  07master * r7d94e9c6b5 10openembedded.git/conf/bitbake.conf: Oct 14 15:55:41 bitbake.conf: resurrect unexported PKG_CONFIG_DIR for installs Oct 14 15:55:41 Signed-off-by: Chris Larson Oct 14 15:55:56 03Chris Larson  07master * rc30bd83438 10openembedded.git/classes/image.bbclass: (log message trimmed) Oct 14 15:55:56 image.bbclass: use un-renamed packages in RDEPENDS Oct 14 15:55:56 The issue was that PACKAGE_INSTALL* get debian package renaming applied, but Oct 14 15:55:56 this renaming is outside of bitbake's knowledge. Making RDEPENDS use Oct 14 15:55:56 PACKAGE_INSTALL, therefore, caused problems when adding libraries to images Oct 14 15:55:56 directly rather than indirectly. Oct 14 15:55:57 While I'm at it, change it to ensure PACKAGE_INSTALL_ATTEMPTONLY packages Oct 14 15:58:32 kergoth_: thanks :) Oct 14 15:58:44 np, and sorry about that, i was the one that broke it :) Oct 14 15:59:00 PKG_CONFIG_DIR isn't needed for the *run* of pkg-config, but apparently is used to *install* .pc files Oct 14 15:59:00 and fixed it fast :) Oct 14 16:06:59 lalala Oct 14 16:08:33 jo effem Oct 14 16:08:41 have a nice rest of day Oct 14 16:09:04 hi all Oct 14 16:09:30 are there any up-to-date instructions for getting OE running on OS X? Oct 14 16:10:40 tasslehoff: it's not going to work out of the box Oct 14 16:10:47 at all. there aren't instructions that would make it work Oct 14 16:10:55 there will be issues, they'll need to be fixed one by one Oct 14 16:11:01 there's a branch that fixes some of it Oct 14 16:11:02 start there Oct 14 16:12:37 kergoth_: ok. thanks. Oct 14 16:12:46 tasslehoff: and please document the steps Oct 14 16:13:03 tasslehoff: oh, please confirm the image.bbclass fix resolves your issue with IMAGE_INSTALL, if you would Oct 14 16:14:56 kergoth_: may I ask you to give alook at this patched recipe? http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=4af226e94d43549ddfaec09fd13980e434baf1b6 Oct 14 16:15:08 there are dubious STAGING vars in do_compile Oct 14 16:15:33 erk, that's really wrong Oct 14 16:15:39 most of that should have gone into do_install, not do_compile Oct 14 16:15:56 ok, I just removed the do_stage Oct 14 16:16:06 he ant Oct 14 16:16:09 no, that wont do Oct 14 16:16:17 ant should I look now into dietlibc? Oct 14 16:16:25 oh, yes, pls Oct 14 16:16:28 just move everything that patch added to compile into install Oct 14 16:16:39 and of course fix the destinations of the installs Oct 14 16:16:42 I syspect there are more cases Oct 14 16:17:09 oh, wait Oct 14 16:17:10 hmm Oct 14 16:17:15 ant hm do_stage Oct 14 16:17:16 we did a first round chasing the do_stage, now we should catch those do_compile :) Oct 14 16:17:25 this is fucking weird Oct 14 16:17:32 will fix this first Oct 14 16:18:03 keep the make in compile -- those header installs are just wrong. figure out why those are there, try removing them Oct 14 16:18:15 the use of STAGING_BINDIR_NATIVE for moc and uic is just fine Oct 14 16:18:39 ok Oct 14 16:18:52 I'm not deep in qt/opie Oct 14 16:18:58 same issues with libopie2 Oct 14 16:19:07 I'll try same cure Oct 14 16:19:15 ant what was usr/lib? Oct 14 16:19:19 libdir? Oct 14 16:21:52 woglinde: where? in the initramfs? Oct 14 16:24:14 ant no Oct 14 16:24:15 in oe Oct 14 16:24:21 so test now Oct 14 16:24:47 libdir -> /usr/lib, base_libdir -> /lib iirc Oct 14 16:26:07 ant hm no compile problems here Oct 14 16:26:14 woglinde: irc segfaulted Oct 14 16:26:31 hm not with gcc-4.5 Oct 14 16:26:38 for qemu-arm Oct 14 16:26:40 ok Oct 14 16:26:59 I'll retry in 2-3 hours at home Oct 14 16:27:13 it was just dietlibc failing, not the utils Oct 14 16:27:19 but I will look at the ccache patch again Oct 14 16:27:29 or was it diet which segfaults= Oct 14 16:27:30 ? Oct 14 16:27:32 I disabled ccache Oct 14 16:27:45 iirc gcc segfaulted Oct 14 16:28:00 immediately after launch Oct 14 16:28:14 bad linking? Oct 14 16:28:23 hm how can I disable ccache for just one bitbake call? Oct 14 16:35:21 heading home, bbl Oct 14 16:36:45 jo Oct 14 16:37:30 eFfeM: ok Oct 14 16:37:40 kergoth_: will do so tomorrow Oct 14 16:38:17 cool, thanks Oct 14 16:38:36 sorry about the hassle, didn't think about the renaming when i made the change Oct 14 16:39:19 kergoth_: no problem. Oct 14 16:39:53 heyho Oct 14 16:40:01 woglinde: CCACHE = "" in local.conf. can't do it via the env, since env doesn't override config files Oct 14 16:40:14 khem: ping Oct 14 16:40:36 tasslehoff: what lib were you trying to add to your image, again? Oct 14 16:41:29 Also, we default to CCACHE being off Oct 14 16:41:31 And have for a while Oct 14 16:41:59 kergoth_: libusb1 Oct 14 16:42:05 tasslehoff: k, thanks Oct 14 16:42:10 hm the segfault is in diet anyway Oct 14 16:42:25 kergoth_: but also got the issue for various qt-libs. Oct 14 16:42:34 * kergoth_ nods Oct 14 16:44:59 * tasslehoff wonders if QxtLogger is easier to get into OE than it is to make log4cxx work Oct 14 16:47:31 tasslehoff: what is the error with log4cxx? Oct 14 16:47:40 tasslehoff: do you have a minimal test case? it segfaults? Oct 14 16:50:09 zecke: it just hangs, strace shows on a futex. I suspect I need to update the recipes for apr and apr-util as well Oct 14 16:50:40 zecke: found a post on google from som log4cxx-people saying "if apr fail, we fail" :) Oct 14 16:51:26 apr suckz Oct 14 16:52:09 woglinde: I fear so, and since I'm only trying to get logging for Qt, I think maybe QxtLogger would be nice. Oct 14 16:54:01 logging for qt? Oct 14 16:54:09 hasnt qt it build in? Oct 14 17:01:31 woglinde: just basic one Oct 14 17:04:28 zecke hm Oct 14 17:04:31 this suckz Oct 14 17:04:47 but we have qtjambi Oct 14 17:04:49 yeah Oct 14 17:14:57 I've been using qDebug, but I need a bit more powerful logging, with the possibility to change loglevel runtime. Oct 14 17:15:43 sure Oct 14 17:15:49 python has it build in Oct 14 17:16:03 haha use pyqt Oct 14 17:16:05 haha Oct 14 17:16:42 ARGGGGGG Oct 14 17:17:18 chouimat? Oct 14 17:18:00 woglinde: received a guruplug tuesday and a) it's bricked or b) the external/jtag interface is caput Oct 14 17:18:47 can get anything on the console and the jtag giving error, I can insert the tiny cable correctly ...300$ in the toilet Oct 14 17:19:38 woglinde: I wanted to use PyQt initially, but the recipe was so outdated back then (and maybe is now) Oct 14 17:22:12 tasslehoff ah right Oct 14 17:22:20 I started to get the latest work Oct 14 17:22:33 but there is something missing somewhere Oct 14 17:32:16 kergoth_: is it koens darwin-host-fixes you mean? Oct 14 17:32:22 yeah Oct 14 17:42:14 tasslehoff: okay, confirmed libusb1 went into the image after the recent fix Oct 14 17:42:45 ok Oct 14 17:43:03 * kergoth_ goes back to testing use of chroots for builds Oct 14 17:47:52 chouimat: warranty ? Oct 14 17:48:09 (or user error?) Oct 14 17:49:36 first hurdle: ERROR: Unable to determine endianness for architecture 'INVALID', and a request to add my architecture to siteinfo.bbclass Oct 14 17:58:04 eFfeM: it's ok ... I'm brain damaged it seems ... I just discovered the correct way of pluging the thing ... Oct 14 18:00:17 :-) Oct 14 18:00:29 glad you didn't break it & have fun with it Oct 14 18:01:01 eFfeM: the tiny cables are sensitive :) Oct 14 18:02:14 * tasslehoff decides that he will use his evening for other things than OE@OSX, and rather focus on dual-booting his Mac. Oct 14 18:02:34 tasslehoff: all my macs are dualboot :) Oct 14 18:03:51 chouimat: I have a MBP6.2 that I'm gonna put either Fedora or Ubuntu on. Ubuntu 10.04 was quite good on my MPB 5.1, except for heat issues. Oct 14 18:05:10 tasslehoff: I have 1 macbook 5,1 with gentoo and a macpro 3,1 also with gentoo ... it's my main development box (I love the fact I have nearly 10TB of hdd and 32GB of ram, works great with virtualbox/vmware setup ;) Oct 14 18:05:51 and I forgot the old ibookG4 (main ppc developement box) Oct 14 18:10:12 chouimat: that sounded like a beast of a machine :D Oct 14 18:10:48 tasslehoff: even the mainframe emulator is fast on this one :) Oct 14 18:10:50 Does your 5.1 get hot, or do you boot it with the internal graphics card? Oct 14 18:11:23 tasslehoff: it's not a macbook pro ... just the plain lowlevel macbook Oct 14 18:12:05 chouimat: ah. read a bit fast there. ok :) Oct 14 18:19:56 How do I tell bitbake to try to get new version of the project if available? I have to run bitbake -c clean everytime Oct 14 18:21:25 Do I want -f? Oct 14 18:24:41 what do you mean? Oct 14 18:24:57 you're going to have to give way more information than that Oct 14 18:25:16 scm uri, i assume? Oct 14 18:34:08 kergoth_: yes Oct 14 18:38:39 what's your SRCREV set to? Oct 14 18:38:50 it sounds like what you really want is to use srctree Oct 14 18:38:55 jo Oct 14 18:40:00 hi bluelightning Oct 14 18:40:07 hi woglinde Oct 14 18:40:35 phew, it's good to finally be back on the net again... moving house is a pain in the uk :/ Oct 14 18:40:50 hihi Oct 14 18:40:52 ask pb Oct 14 18:40:55 ~seen pb Oct 14 18:41:10 pb was last seen on IRC in channel #tomcat, 720d 23h 55m 13s ago, saying: 'arghh'. Oct 14 18:41:15 ~seen pb_ Oct 14 18:41:17 pb_ is currently on #oe (9h 38m 42s), last said: 'heh, indeed'. Oct 14 18:41:26 ah he isnt dead Oct 14 18:49:42 morphis: yes Oct 14 18:50:23 jo khem Oct 14 18:50:49 woglinde: are you going to ELS Oct 14 18:50:51 ELCE Oct 14 18:50:55 khem no Oct 14 18:50:58 no time Oct 14 18:51:15 woglinde: oh ok. Exams ? Oct 14 18:51:47 yes and talk about masterthesis Oct 14 18:54:17 woglinde: ok Oct 14 18:54:22 good luck Oct 14 18:54:33 woglinde: are you berliner Oct 14 18:54:39 Tartarus, talk about meta-toolchain a min? want to understand better about libc deps. Notice that current toolchain builds gcc with so's for libc - I'm curious why its not static? Oct 14 18:54:40 ich bin ein berliner :) Oct 14 18:54:54 khem yes Oct 14 18:56:04 tharvey, with the static linking of libs that we do, we avoid specific library problems Oct 14 18:56:14 But we still have the general worries to worry over Oct 14 18:56:36 right, so why does meta-toolchain build a gcc that does not have libc static linked? Oct 14 18:56:47 adn what are the general worries? Oct 14 18:57:00 because until now, no one has given a shit if a given built toolchain is very portable, would be my guess Oct 14 18:57:04 sad, but probably true Oct 14 18:57:07 :P Oct 14 18:57:23 kergoth_: yes and building a portable toolchain is a different beast Oct 14 18:57:25 :) Oct 14 18:57:27 tharvey, well, in general, go hit the LSB pages up for a "why we exist" :) Oct 14 18:57:40 Then the next problem is that LSB isn't good enough to build gcc Oct 14 18:57:43 I know it very well from personal experiences Oct 14 18:57:51 So we'd have to -static gcc & co Oct 14 18:57:58 And try and lsb build the rest of the apps in m-t Oct 14 18:58:19 just blindly -staticing the tools would work better than nothing, i suppose. i wonder how massive the toolchain would be Oct 14 18:58:29 Or you can do what CSL does Oct 14 18:58:34 Build on an ancient-ass host :) Oct 14 18:58:41 heh Oct 14 18:59:20 yeah, buliding it on an old ass chroot would work Oct 14 18:59:21 It's a valid solution, imho Oct 14 18:59:23 should try that Oct 14 18:59:27 i agree Oct 14 18:59:28 LSB cannot build gcc & co Oct 14 18:59:41 So that's why I was saying we do u804 last night Oct 14 18:59:52 It's old enough to be supported for what we care for, for Ubuntu hosts Oct 14 18:59:55 heh use OE to build an ancient root Oct 14 18:59:57 but not so old that it's a royal pain Oct 14 19:00:01 then build the toolchain Oct 14 19:00:03 and back to building on an ancient host, like u8.04 - thats useful because libc backwards compat is good, but there is no facility for an older host to necessarily be compat with something output from a u10.10 compile right? Oct 14 19:00:32 Right, the forward compat facility is building things as LSB vN compliant Oct 14 19:00:43 khem: I did the patch for libgee and send it to the ML, can you please review it? Oct 14 19:01:09 morphis: yes the patch was ok and built libgee fine here I applied it alreayd Oct 14 19:01:42 ah ok Oct 14 19:01:44 you applied both? Oct 14 19:01:48 yes Oct 14 19:02:00 * kergoth_ builds a bunch of fedora chroots in a VM Oct 14 19:02:04 good patches are taken care of :) Oct 14 19:02:16 khem: great, than I don't have to do that :) Oct 14 19:02:45 morphis: yes Oct 14 19:02:59 khem: thank you very much Oct 14 19:03:02 03Tom Rini  07org.openembedded.dev * ra527c04a25 10openembedded.git/.gitignore: Oct 14 19:03:02 .gitignore: Add .pyo files, expand contrib mask Oct 14 19:03:02 Signed-off-by: Tom Rini Oct 14 19:04:29 Tartarus, ok, so I see that if your trying to create a toolchain useful for older distros as well as newer you would want to build on the oldest distro you wish to support 'if' you dynamically link libc, still not seeing why statically linking it isn't a better choice Oct 14 19:05:03 tharvey, Getting gcc & co to do what you want can be difficult at times Oct 14 19:06:28 kergoth_, re chroot, I understand what the cmd does and all, but how are you going about building a chroot filesystem - I assume you simply install a VM for the particular distro and tarball up its root? Oct 14 19:06:58 tharvey, depends on the distro Oct 14 19:07:00 Tartarus, so are you saying there are less compat issues by using dynamic libc and building on an older host vs using static on a current host distro? Oct 14 19:07:03 no, there are generally tools available to build chroots if you're running on the distro (e.g. debootstrap, febootstrap, mock (iirc), sbuild (uses debootstrap), etc) Oct 14 19:07:15 tharvey, yes Oct 14 19:07:55 kergoth_: are you going to propose a patch to reverse the OVERRIDES order Oct 14 19:08:06 yeah, i'll send one out today, thanks for the reminder :) Oct 14 19:10:13 Tartarus, can you give me more detail on the compat issues for using a static toolchain on older host built on newer? is it simply that the LSB 'changes' over time so breaks compat or is there something else? Oct 14 19:12:10 LSB is the alternative solution Oct 14 19:12:22 it would let you build on u10.04 for examlpe and run on u8.04 Oct 14 19:12:35 But it's not a complete set of headers and such enough to build gcc Oct 14 19:12:57 (LSB is basically its own devel time headers and so on) Oct 14 19:13:07 kergoth: why dont we generate or prefer to generate target packages with cross recipes Oct 14 19:14:22 not sure what you mean Oct 14 19:15:16 the packages that come out of cross would be and should be cross packages intended for use on the build machine, e.g. into an sdk, in my opinion. having target things come out of a cross recipe is just asking for trouble, and asking for conflicts with the actual target version of the recipe Oct 14 19:16:23 kergoth_: hmmm so to stick with this policy gcc-cros should be divided Oct 14 19:16:28 then Oct 14 19:16:33 i think so Oct 14 19:16:41 not sure what others think, but i suspect thats the common view Oct 14 19:17:10 I fear backlash on telling devs that now they have to build gcc yet another time Oct 14 19:17:26 or better may be I can alter the build sequence Oct 14 19:17:37 so I can prolly cut down on one pass Oct 14 19:17:48 We really need to think about how we do the gcc dance, yes Oct 14 19:17:53 which may or may not be possible Oct 14 19:18:02 If we can reduce the overall build time, people will be happy Oct 14 19:18:15 Tartarus: I have thought quite a bit what we do it the best at the moment Oct 14 19:18:56 Tartarus: another way could be if we shared object trees Oct 14 19:19:06 but with OE/bb its not the right way Oct 14 19:20:07 Can someone give me the link to the _kernel_ git tree that OE uses in the compilation of the overo kernel ? Oct 14 19:20:42 mpoirier: look into the recipe's SRC_URI Oct 14 19:20:45 i'm wondering why you can't find it yourself in the recipe, either local or via gitweb.. Oct 14 19:28:40 mpoirier, you have to follow the recipes (can be tricky) or just do a MACHINE=overo bitbake -n virtual/kernel and see what pops out at the end Oct 14 19:29:14 tharvey: that is interesting - hold on. Oct 14 19:29:35 kergoth_: with libtool 2.4 it would be better that we split up gcc-cross Oct 14 19:30:03 mpoirier, I believe its linux-omap-psp-2.6.32-r90+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869 at the moment Oct 14 19:30:04 so I am gonna do it instead of painting more mud on current stuff to get it working Oct 14 19:30:54 mpoirier, but I think overo is broken currently - at least it wouldn't build bootloader for me the other day and I haven't had time to see if its fixed yet or what the issue is Oct 14 19:31:29 mpoirier, the OE git trunk has been very unstable for me lately for overo images/toolchain as well as other things Oct 14 19:31:45 tharvey: I'm only concerned about the kernel itself. Oct 14 19:32:07 tharvey: I have a mainstream kernel but display isn't working. Oct 14 19:32:21 OE has the patch set to get this going. Oct 14 19:32:25 tharvey: hmmm Oct 14 19:32:25 That is what I'm after. Oct 14 19:34:51 mpoirier, display on what device? Oct 14 19:35:23 tharvey: here's a better question... Oct 14 19:35:53 khem, I was referring to that gdb-cross-sdk issue that was fixed yesterday and to some breakage that occured late yesterday regarding lib and popen which was fixed 4 hours later - its a total crapshoot when you pull these days :P Oct 14 19:36:07 at least if your doing 'clean builds' to sanity check a snapshot Oct 14 19:36:34 tharvey: its master so some allowence for breakage should be given Oct 14 19:36:56 tharvey: what cbrake started with weekly testing is helpful Oct 14 19:37:02 under recipies/linux/linux-omap3-2.6.29, there is a file called "dss2.patch". Oct 14 19:37:08 and we should plan on biannual releases Oct 14 19:37:27 which will make master a bit better place to commit changes and users can still have releases Oct 14 19:37:40 tharvey: would you know where these patches come from ? Oct 14 19:37:57 imo a project that does not have release is doomed Oct 14 19:39:12 We have to automate the builds I am looking into hudson etc. Oct 14 19:39:39 tharvey: display on overo Oct 14 19:39:41 that will help us improve the quality Oct 14 19:41:20 khem, completely agree about the releases - wasn't aware there was any plan? A bi-annual branch/freeze/fix sounds like a good plan Oct 14 19:41:41 there isn't a plan, not exactly -- but it is an agenda item for oedem Oct 14 19:42:27 yes I am very interested in making it happen Oct 14 19:42:48 even if we start with annual release to begin with is not bad Oct 14 19:42:59 we will only test certain combinations Oct 14 19:43:02 6 months seems to be a very common release cycle Oct 14 19:43:10 as described on Testing page Oct 14 19:43:15 and make the releases Oct 14 19:43:44 if one wants the combinations to be included in test cycles then adding to that page is the way Oct 14 19:44:09 and if I am successful with hudson then day today breakage should be taken care of too Oct 14 19:44:27 usually master is very good Oct 14 19:45:35 tinderbox with the class seems like a great way of doing things, i like how it submits the data -- could use hudson to trigger periodic builds, and use the tinderbox to *view* it, rather than hudson's crap Oct 14 19:46:35 yeah it will interface into tinderbox Oct 14 19:46:44 and prolly send emails to committers Oct 14 19:47:18 can you guys put together something we can use for release cycle discussion at OEDEM? Oct 14 19:48:00 Crofton|work: its just on aside right now Oct 14 19:49:19 I suspect it may come up in discusssion Oct 14 19:49:46 i'm not sure much needs to be written up -- the idea of a release process is pretty self explanatory, no? Oct 14 19:50:43 that is, but how do we get to something worth releasing? Oct 14 19:50:52 release process should be considered important part in OE's future Oct 14 19:50:53 and what is worth releasing Oct 14 19:51:07 Crofton|work: I just explained few things Oct 14 19:51:09 above Oct 14 19:51:14 thats a start Oct 14 19:51:23 Anyone used xlib? I need libXxf86vm. I need xf86vmode.h. 'angstrom-setup-scripts/build/tmp-angstrom_2008_1/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/X11/' is where Xlib.h is but there's no extensions. Is this a dependency issue? Oct 14 19:51:24 we only release test on given combinations Oct 14 19:51:56 I haven't been able to wrap my head around tinderbox - never seems to give me the info I want or perhaps I'm just not clear how to get at it Oct 14 19:52:05 cbrake's testing is a great step in the right direction, and the sort of thing we should do -- note in the release notes what's confirmed sane Oct 14 19:52:18 mpoirier, most people doing overo work use the gumstix repo Oct 14 19:52:19 I would agree that in the past it seemed master was fairly stable I think I just have had some bad luck recently doing pulls at exactly the wrong time Oct 14 19:52:47 http://tinderbox.openembedded.net/builds/96044/ - *our* tinderbox is quite simple and straightforward, i think Oct 14 19:52:51 others i've seen, not so much Oct 14 19:52:57 heh Oct 14 19:52:59 and I have found often that while a pull and build w/o clean works, a clean build does not - wondering how many people are doing clean builds. Its not sane to do a clean build prior to every commit :P Oct 14 19:53:32 i pretty much always do clean builds, personally Oct 14 19:53:36 tharvey: I do build from scratch almost every day Oct 14 19:53:48 and x11-image usually works Oct 14 19:53:56 sometimes I have issues Oct 14 19:54:11 there still are some races I think but they can be chased Oct 14 19:54:14 kergoth_, tinderbox doesn't seem to tell you what ver of master they built on and doesn't tell you if its a clean build - these are critical issues Oct 14 19:54:28 khem, for what machine(s)? Oct 14 19:54:59 Crofton|work: I used the following: git clone git://gitorious.org/gumstix-oe/mainline.git Oct 14 19:55:14 tharvey: what do you mean? Oct 14 19:55:18 of course it tells you if its a clean build Oct 14 19:55:23 look at the build, look at what it builds Oct 14 19:55:35 if it didn't build shasum-native and shit, its clearly not from scratch.. Oct 14 19:55:36 gumstix seem the same as min2440 Oct 14 19:55:47 user alaways complains nothing is working Oct 14 19:55:59 if you have issues with that, post on the gumstix list Oct 14 19:56:29 kergoth_, when I say clean I don't mean clean that package, I mean wipe out TMPDIR completely - trust me I've had issues that don't pop up until you do that Oct 14 19:56:38 yes, i know what you mean. Oct 14 19:56:44 there's no confusion there Oct 14 19:56:48 Crofton|work: I don't have issues - things are compiling along quite nicely. Oct 14 19:56:53 openembedded never uses the files in /usr/include right? Where does it get the machine specific header files? Oct 14 19:57:00 well, ignore me then :) Oct 14 19:57:02 foobaz: look in tmp/sysroot* Oct 14 19:57:12 Crofton|work: I just want to know where the dss2 are coming from... Oct 14 19:57:32 dss2 patches? Oct 14 19:57:40 Crofton|work: yes, please. Oct 14 19:57:42 Look in the linux-omap3 recipe Oct 14 19:57:54 I think that is the one gumstix-oe actuall builds Oct 14 19:58:00 they may be in a git repo Oct 14 19:58:29 Crofton|work: I'm in recipies... Oct 14 19:58:55 kergoth_: I need X11/extensions/xf86vmode.h but it's not there. am I out of luck or are they set up with a dependency? Oct 14 19:59:13 foobaz: nothing is magically put there, ever. if you need something, depend on it, or don't expect to be able to use it Oct 14 19:59:15 Crofton|work: under linux/linux-omap3-2.6.29 is a file: dss2.patch Oct 14 19:59:24 Crofton|work: that's what I'm after. Oct 14 19:59:51 Crofton|work: I want to have a reference to the git tree where these patches come from. Oct 14 20:00:10 ah Oct 14 20:00:15 maybe from the mailing list Oct 14 20:00:24 kergoth_, I likely just don't understand tinderbox. I think of a build as building a filesystem image, which results in building all the deps for such - all I see in tinderbox is individual packages and its not clear what triggered them to build. I dont' see a way to go and say, show me the results of master branch at commit xyz building from scratch (wiped TMDIR) a package Oct 14 20:00:31 kergoth_: ah okay. How do I know what to depend on? I've been looking around and I can't find the name. libX11 was easy to find since I saw an example. Oct 14 20:00:52 no, tinderbox has a notion of builds, a build is a single bitbake command, which builds multiple packages. Oct 14 20:01:04 there's no way to tell tinderbox whether its "from scratch" Oct 14 20:01:19 i'd think itd be fairly easy to tell it the master revision, but i dunno, i didn't write the code for it Oct 14 20:01:50 also bothers me to no end that I can't post a tinderbox URL - it doesn't put the search criteria on a URL Oct 14 20:02:20 so for example... goto http://tinderbox.openembedded.net/search/ select Distro angstrom, Machine overo and 'submit' and look at the results - tell me how stable that looks to you Oct 14 20:02:57 my screen is bleeding bad when I look at those results heh Oct 14 20:03:29 ah... and there it is 'u-boot-omap3' failing for others as well... something broke recently regarding that Oct 14 20:05:33 tharvey um? wasnt there a lot of fixes the last day? Oct 14 20:06:07 khem_, you say you build from scratch almost every day, but when I goto tinderbox and look up your stats I don't see anything that recent - last built for minimal distro on 9/30 for example ? Oct 14 20:06:32 woglinde, don't know... hard to look at commit log and determine fixes from breakages Oct 14 20:06:42 only a build tells you which they are :) Oct 14 20:07:41 and perhaps its what I'm building that isn't stable - ie I build console-image and meta-toolchain - meta-toolchain was not building for me for some time until fixes yesterday Oct 14 20:08:04 wasn't clear to me why nobody else was noticing other than perhaps nobody else cares to build meta-toolchain Oct 14 20:11:00 completely different topic but how are people getting around the i386 issue in recent distros with gzip? (https://bugzilla.redhat.com/show_bug.cgi?id=588644) - are you all just installing your own gzip? Was wondering if there was discussion on building gzip native or something Oct 14 20:14:40 our gzip does have a bbclassextend set to native, so you should be able to bitbake gzip-native if necessary Oct 14 20:16:46 guess the issue just doesn't affect enough people to warrant building that automatically in the toolchain? Oct 14 20:27:15 hm, i get: Oct 14 20:27:16 NOTE: multiple providers are available for runtime libmysqlclient (mysql5, mysql) Oct 14 20:27:19 tharvey: I dont use tinderbox from this box Oct 14 20:27:30 tharvey: but I do use for testing builds Oct 14 20:27:33 but in my local.conf I already said: Oct 14 20:27:34 PREFERRED_PROVIDER_libmysqlclient = "mysql5" Oct 14 20:27:52 what's wrong/how should i resolve this ? Oct 14 20:29:25 weird, that should be working Oct 14 20:29:41 * kergoth_ kicks binutils-cross Oct 14 20:30:00 kergoth_ that is what I also expected Oct 14 20:30:08 tharvey: would be nice if tinderbox knew about build machine distro too Oct 14 20:30:28 * kergoth_ is separating them by hostname at the moment, but still Oct 14 20:30:59 will see -f -D -D -D gives something Oct 14 20:31:43 kergoth_: thanks yeah I needed libxxf86vm as a dependency. Oct 14 20:49:21 kergoth_ wrt the libmysqlclient thing: if I enable debugging I get this: http://www.pastebin.ca/1962457 Oct 14 21:01:35 jo ant Oct 14 21:02:02 hello, building dietlibc now... Oct 14 21:06:51 woglinde: :/ Oct 14 21:06:54 dietlibc-0.32 bin-i386/diet gcc -isystem/oe/build/tmp/sysroots/i686-linux/usr/include -O2 -g -o bin-i386/dnsd contrib/dnsd.c Oct 14 21:06:54 | make: *** [bin-i386/elftrunc] Segmentation fault Oct 14 21:08:32 ant dont get it Oct 14 21:08:40 ant are you building on 64 biz? Oct 14 21:08:51 I tested here both with ccache and without Oct 14 21:08:56 no, Ubuntu 32 bit Oct 14 21:08:57 and it worked Oct 14 21:09:29 Ubuntu 10.04.1 LTS Oct 14 21:10:01 no ccache installed Oct 14 21:10:20 sorry I am puzzeld Oct 14 21:10:28 same failure in Gentoo 32 bit months ago Oct 14 21:10:41 fwiw Oct 14 21:10:49 | make: *** [bin-i386/dnsd] Segmentation fault Oct 14 21:10:51 too Oct 14 21:11:10 03Henning Heinold  07org.openembedded.dev * ra14a6463ae 10openembedded.git/recipes/disko/ (disko_1.7.0.bb files/mmsfiletransfer.patch): disko: update to version 1.7.0 Oct 14 21:11:47 I have debian sid here Oct 14 21:12:02 is elftrunc compiled? Oct 14 21:12:06 elftrunc.c Oct 14 21:12:10 let say..one year ago was posible to build it Oct 14 21:13:00 hm Oct 14 21:13:16 I am now seeing I am not honor the machine specific ldflags Oct 14 21:13:41 but thats a diffrent matter Oct 14 21:14:02 no, I don't see elftrunc.o Oct 14 21:14:51 whats the last line before dns? Oct 14 21:15:17 and elftrunc is executebal Oct 14 21:15:21 not object file Oct 14 21:16:51 woglinde, http://filebin.ca/yvenoa Oct 14 21:17:00 log_do_compile Oct 14 21:17:09 hm Oct 14 21:17:14 paste the one line here Oct 14 21:17:21 I already closed the browser Oct 14 21:17:29 I am on way to my bed Oct 14 21:17:54 DIETHOME=/oe/build/tmp/work/armv5te-angstrom-linux-gnueabi/dietlibc-0.32-r2.2/dietlibc-0.32 bin-i386/diet gcc -isystem/oe/build/tmp/sysroots/i686-linux/usr/include -O2 -g -o bin-i386/elftrunc contrib/elftrunc.c Oct 14 21:18:03 okay Oct 14 21:18:19 ant dont know Oct 14 21:18:42 if diet were broken this line wouldnt compile too Oct 14 21:18:55 okay good nite Oct 14 21:19:03 nite, thx Oct 14 21:19:21 hm maybee trying to debug with gdb? Oct 14 21:19:26 or with strace Oct 14 21:19:36 calling it by hand Oct 14 21:20:05 well, elftrunc.c is just a couple of kb... Oct 14 21:32:42 03Tom Rini  07org.openembedded.dev * ra4a5808f9a 10openembedded.git/recipes/gdb/ (gdb-cross-sdk.inc gdb-cross.inc gdb.inc): Oct 14 21:32:42 gdb (all): Add bison-native to DEPENDS Oct 14 21:32:42 While in here, noticed that I didn't do the second half of Oct 14 21:32:42 8b2cac31bec0b97c8bc66ff3e6d2c9903f2ae8dc as I intended and Oct 14 21:32:42 actually delete the DEPENDS line here. Oct 14 21:32:42 Signed-off-by: Tom Rini **** ENDING LOGGING AT Fri Oct 15 02:59:57 2010